Slashdot Mirror
Ask Slashdot: Share Your Security Review Tales
New submitter TreZ writes: If you write software, you are most likely subject to a "security review" at some point. A large portion of this is common sense like don't put plain text credentials into github, don't write your own encryption algorithms, etc. Once you get past that there is a "subjective" nature to these reviews.
What is the worst "you can't do" or "you must do" that you've been subjected to in a security review? A fictitious example would be: you must authenticate all clients with a client certificate, plus basic auth, plus MFA token. Tell your story here, omitting incriminating details.
What is the worst "you can't do" or "you must do" that you've been subjected to in a security review? A fictitious example would be: you must authenticate all clients with a client certificate, plus basic auth, plus MFA token. Tell your story here, omitting incriminating details.
If you write software, you are most likely subject to a "security review" at some point
Wrong! My code has never been subjected to any such stupid security review.
Disclaimer: Opinions expressed here are mine, not my employer Equifax.
Disclaimer to disclaimer: Nah! I'm not really working for Equifax
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
>> What is the worst "you can't do" or "you must do" that you've been subjected to in a security review?
Anything the client didn't pay for. (Threats to suspend a very large support payment count as payment, however.) Likewise, whenever a customer wanted to pay extra for an MFA, SSO or other integration, we were all ears.
Or were you looking for whining?
Working for a semi-well known mesh networking company in Seattle, I was hired for DevOps because, despite 20+ years experience with C/C++, the gasseous CTO didn't believe I was qualified to do development. About a month into the job, I got called into a code review for one of the senior developers, and I quickly caught several buffer overruns on the "rookie mistake" level with strncpy overflowing the allocated space.
Gotta wonder how many of those Mr. Senior Developer committed to the code base.
I was a high-ranking official in the state department. The FBI sent me a subpoena for my private email server because I used it to discuss classified government business, so I had my IT guy wipe my private email server before I handed it over to the FBI. Later he was discovered on Reddit and confessed to the FBI, but I made sure they couldn't trace the decision back to me.
This happened to a customer of us: They were told by an auditor that they absolute must have anti-virus on all machines, as per policy. Hence they built a tunnel into a completely isolated environment with absolutely no malware-vectors in order to be able to get updated AV signatures to the AV they installed on these machines. The really bad thing was that they did not seem to understand when we explained to them that they now did not have an isolated environment anymore and that the AV vendor as well as anybody successfully attacking the AV vendor could now attack them and export data at their leisure. What they should have done is to get an exception.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Never trust management. They oversimplify and are totally defenseless against hype.
My five cents.
At my office, no one has physical access to their machines. They are all locked in shielded cabinets. We get a keyboard, mouse, and monitor. No access to USB, Network, or any other ports.
No network connection by any means to the Internet, and no cell phones are allowed in the building, period.
Place is pretty tight.
I'm not sure there is such a thing as a completely isolated environment anymore. There are too many air-gap bridging attacks. (See also Stuxnet).
Now, those attacks require far more work than the anti-virus vector. And it's not likely to be used. But it should be expected that something valuable enough (to a nation state) will be breached.
Your ad here. Ask me how!
I worked for a startup as a contractor, and they were readying a security product to hit the market. It used public and private keys. Instead of generating and using a 4096 bit key (for securing files), it used sixty-four, 64-bit RSA keys. The reason for this is that the CEO wanted the ability to decode stuff in case a customer locked themselves out.
Worst:
I use to work for a company, about a year ago, where no one had even the most basic concept of data security. During my time there I implemented MFA on all Servers, programmed in Data Encryption, Data Validation, Client Verification, DB Security and other such improvements. Well, I was showing the three other existing employees how the software worked and how the new infrastructure worked, they didn't like that it was now "hard" to log into the servers and that they would now have to use password and keys to access Data. They told me to revert to how it was before, as they knew better then I did, so I quit. The software product they're developing, without a developer (they still don't have one), is an iSCSI based Desktop Protection System, but it's so riddled with holes and such a massive lack of security that they're committing fraud by selling what they have as a security solution.
Best:
Some software I was involved with developing had to undergo a security review. Little did I realize how unprepared for this event I was!
It started off relatively benignly. I was sitting in one of the conference rooms, waiting for the external security consultant to come in. He arrived a minute or two after I had arrived.
"Hello.", he started off. "I'm Steve and today we'll be performing a security review of the software you and your team have developed." He opened his laptop and started loading up the source code we'd provided to him earlier. He didn't even bother with any sort of friendly small talk.
"So I see you chose C++." he said after a minute or so of looking at the code.
"Yes, C++14.", I confirmed.
"Unacceptable.", he stated without hesitation.
I was slightly taken aback. "Pardon?", I asked.
"C++ is unacceptable.", he stated.
"We're using modern C++ techniques, including smart pointers and RAII. We also run our code through several static and dynamic analysis tools.", I explained.
"C++ is unacceptable.", he repeated.
We sat in silence for a couple of minutes as he continued to scroll through the code.
"Why didn't you use Rust?", he finally asked.
"Rust?", I replied. "We started this project before Rust 1.0 had been released. Plus our team is more familiar with C++."
"C++ is unacceptable.", he repeated once again.
He was starting to get agitated. "Why the fuck didn't you use Rust?!" he asked once more.
"I just explained why.", I responded.
"Don't you give a fuck about guaranteed memory safety? Don't you give a fuck about threads without data races?", he asked loudly.
"Well, yes, I do care about such things. But we can achieve those by using modern C++ sensibly."
As expected, he replied "C++ is unacceptable. C++ is fucking unacceptable."
I wasn't really sure what to do at this point. Clearly he didn't think C++ was an acceptable language to use.
My pondering was cut short. He abruptly started screaming, "WHY THE FUCK DIDN'T YOU USE RUST?! DON'T YOU GIVE A FUCK ABOUT ZERO-COST ABSTRACTIONS?!"
"C++ usually has zero-cost abstractions.", I pointed out.
This sent him over the edge. His face started getting a very deep red color, and I could see he was getting extraordinarily angry. "C++ IS UNACCEPTABLE! C++ IS UNACCEPTABLE! YOU HAVE TO USE RUST! RUST IS THE ONLY PROGRAMMING LANGUAGE THAT RUNS BLAZINGLY FAST, PREVENTS SEGFAULTS, AND GUARANTEES THREAD SAFETY!"
At this point I was starting to fear for my safety. I had read comments from Rust fanatics online, at places like Hacker News and Stack Overflow. But I had never expected these Rust advocates to be as egregiously agitated as this security consultant was.
Noticing that the door to the conference room was slightly open, and thankful that I was sitting closer to the door than the consultant was, I made a dash for freedom. I slipped through the door, and immediately started running toward my manager's office.
All the way I could hear the consultant screaming, "C++ IS UNACCEPTABLE! YOU NEED TO USE RUST BECAUSE IT HAS TRAIT-BASED GENERICS AND PATTERN MATCHING!"
I quickly explained the situation to my manager, who was wondering what all of the yelling was about. He quickly dialed the office building's security team, but they must have been alerted beforehand by somebody else, because the consultant's yelling abruptly stopped mid-way through a rant about the importance of move semantics.
To be perfectly honest, I have no idea what happened in the end. I assume the security consultant was promptly removed from the building. As for the security review of our software, I haven't heard about having to do any additional ones. Perhaps management realized that there were better uses for our time than listening to some lunatic berate us for using C++ instead of Rust.
Some nosyparker busybody customer did a "strings" on our product and found the string and ratted out to our CTO. Nothing serious happened, just a slap on the wrist. But another colleague told me the same customer found the full "man from nantucket" in his test strings for the stringutil library he wrote. And another said that customer also found the "Fuck! Got null pointer again!" in his code.
We think he was looking for some kind of debug switches and env settings that will disable license check.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
I was summoned by a contract firm to a 500 person company that had been a victim of an inside job. They wanted a security review and fixes for "whatever that guy did". Turns out the guy was a half-assed developer. The client had spotty and in some cases non-existent backups. They wanted to pass a SOX audit (hahahaha!) while 20-30 machines were completely pwned and backdoored. He'd used everything from sub7 to more modern remote access & control tools. Some of the tools looked like ones he'd cobbled together himself from other tools. He'd also got in and falsified and buried a bunch of code hacks in their version control repo. Luckily, I was able to get that off tape and they only lost about a MONTH of code/work. The FBI got involved because the guy was out of state. I spent about 3 weeks gathering evidence and rebuilding servers, routers, print-servers, and other devices he'd hacked or otherwise tainted. My fees amounted to around $30k. A federal DA charged him with about 10 different hacking related and felony vandalism charges. After a pretty short trial (no jury) he was found guilty and he's still in the same federal prison in Louisiana. He actually has a cell near Bernie Ebbers. I had to talk to him once while he was in prison to get some passwords. The whole thing was surreal. Now get this, on the SOX audit? They passed! They got dinged for the hack but they still passed even before I was done cleaning up. That's when I realized that CISSP/SOX/GLBA/PCI security and *actual* IT security aren't always aligned. Audit all you like, but ... "stay frosty and alert. You can't afford to let one of those bastards in here."
I'm not sure there is such a thing as a completely isolated environment anymore. There are too many air-gap bridging attacks. (See also Stuxnet).
In practical terms, an isolated environment is one where the only way anything gets into the system is by a human being manually entering it, and the only way anything gets out by what a human being carries away with him either in his head or in his pocket/breifcase/other.
I would count a system that has a keyboard or mouse for input, a video screen, printer, and maybe a "write only" media-writing tool (see below) that is in a room where electronic- or even look-at-the-screen-through-the-window eavesdropping or jamming is either impractical or not a concern to to meet these requirements.
More common would be "one way isolation" where the system was closed to input except from a human, but it's output was no secret. For example, my microwave oven's firmware cannot be changed without replacing hardware. But I can provide input to it through the keyboard and I can change its "state" by putting different kinds of food or other objects inside it or by varying the electrical input on the 120V line input. If I pretend it's plugged into an isolated off-the-grid power supply and the whole thing is in an access-controlled building, it's now a closed system as far as input is concerned, but the output - energy to the food and a small but detectable leakage of microwave energy into the environment, as well as detectable changes in the power supply system - is not closed.
I expect that such embedded systems which are, in practical terms, isolated as far as input is concerned, are much more common than you might think.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
You are telling me that the staff member who was running the meeting or the senior staff member in the room didn't intervene as soon as he started acting unprofessionally?
Being anti-RUST or whatever I can see. Being closed-minded to the point of being useless as a consultant I can see. But an invited outsider who gets unprofessional in a meeting should be reminded to be professional and/or removed before things get out of hand.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
yeah, thanks, i was like hmm. i can't delete or edit, someone will fix it for me. ;)
*WHOOOOOOOOSH*
file:
I have been a developer since about 1990 and I have been occasionally re-purposed to perform security reviews
The first time was in 2000, we were a data center that was part of a fairly new fiber company.
We were in a partnership with a large document management company and some open source organization.
The website that we were hosting kept crashing and the PM responsible for it had lost the admin password.
It ran on Oracle and I was able to use some default passwords and os level functionality in Oracle to grep the file system and identify the system passwords.
Unsurprisingly, I found that they were using commonly known passwords that were present throughout their training materials
When I asked if they could change the default passwords to new values, and rotate them regularly, the response was "No, we think that will break everything"
This resulted in two things, I because the Unix security guru, and I got them kicked out of our datacenter.
Similarly, one day our SAN admin noticed that DVD images were being stored on our SAN. We traced it back to another start-up that had been using TELNET to log into their box as root. Apparently this traffic had been sniffed out and our systems had been compromised. This resulted in a clean-room rebuild of all active systems and me being tasked with writing security policies to publish to our customers, follow them and be welcome, don't follow them and buh-bye...
You may notice that this is all being done in a completely reactive manner since at that time, apparently, nobody in the fucking planet had a clue about how to build and admin a secure system.
Since that time I have fought the "make a system where you can change the default passwords", "Keep your systems patched up the currently available level", "why the fuck are you passing strings to your database without scrubbing them", and "sure, that is what you think your firewall is doing, but it is not really doing that" battles over and over and over.
They say that security starts at the code level, and you can really fuck yourself over by taking a poor approach, but most security problems are just plain piss-poor admin skills. IMHO
Common Sense? A set of assumptions, usually false acquired before age 18.
BOFH would have asked him to plug in the waffle iron.
Years ago, I was making a website for a company that shall remain nameless. They wanted an online ordering system built. No problem. I can do that. Then, they told me they wanted the order information to not be saved into a database, but e-mailed to them. I pushed back as much as I could, but finally had to build it for them. (It's complicated as to why I couldn't just say "I refuse" and walk away. Trust me, had it been up to me, I would have.)
A few years later, they came to me saying they had a complaint from a user who discovered that their full credit card information was being e-mailed insecurely. In my head, I shouted "I TOLD YOU SO" while outwardly I pitched a database-based system that they finally agreed to.
My sci-fi novel, Ghost Thief, is now available from Amazon.com.
Like rust?
Gamingmuseum.com: Give your 3D accelerator a rest.
False Positives during automated audit tools is my own personal hell. PCI Compliance demands these audits be ran every quarter. And every quarter, our Windows 2012r2 server which is only used for a couple of people to work remotely fails the audit. Which test does it fail? The audit claims it is vulnerable to a Windows NT4 terminal services exploit. The exploits have long been patched by Microsoft, plus the effected cyphers have also long been disabled. Yet every single goddamn quarter, we fail the audit, and it is usually a month long battle with one-way messaging to the audit company to let them know their still a bunch of morons. And guess what? The quarter just started this week!
We have an external company that does penetration testing, which definitely find stuff we don't catch in code reviews.
This one was. Sorry cannot get into details.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Actually, they had to put the tunnel in first for that, and, just as a hint, that required drilling an armored and shielded wall. The exception would have been exactly the right thing to do.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Should have built your own open source anti-virus as a 'side' project. It could scan for a few signatures or something. It doesn't even have to work, that's not a requirement for anti-virus: all you need is a website that looks really snazzy.
No one buys anti-virus because it works, they buy it because of marketing.
"First they came for the slanderers and i said nothing."
So we had a third party audit team come in to insure we were in compliance with appropriate security regulations.
My app is essentially a scripting service internally to make it easier to connect various functions together. We don't generate data, we only take data from inputs or pull from encrypted databases (if it's sensitive data) and we only store working data for as long as the script runs. We're a web service so we use SSL for all communications and any temp storage is stored in an encrypted state too except for things related to script processing (running state, launcher process, etc) which should never have sensitive data in it to begin with.
So we explain this to the audit crew which is obviously used to one way systems (data being generated or data being stored - not a dynamic system that generates actions on the fly) and the first thing they ask is - "How are you guaranteeing that sensitive data is being encrypted?"
"We're encrypting it all...?"
"But how do you know when you're getting information like credit card numbers?"
"We don't. Data is handed to us and we process it and return the results."
"But how do you know it's secure?"
"Because we encrypt it on the input and output pipes and store it encrypted on any external systems which are also on SSL pipes. Internally we don't decrypt until the data is needed and no process data is logged aside from metadata of the state."
"But how can you guarantee it's secure?"
I'll admit, I fell for it. Between the rare-but-not-unheard-of cases of previously-rational people "going off the rails" and corporate-types being too polite to shut down a meeting once someone drops the f-bomb, it had just enough plausibility to get past my "this has to be a joke" filter.
All in all though, I'd much rather fall for this joke than have it be real.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
In 1999 I was hired by a Midwestern telco -- in the interests of not getting sued I won't say which: I'll just say their market cap used to be in the billions and now you could buy them with the lint in your pocket -- to do security remediation on their billing system. I spent weeks poring over architectural diagrams, going through source code, examining protocols. After a while I realized I had some really scary information, so I asked my manager for a safe.
"Just put it all in a binder," she said. "We trust you to keep an eye on it."
The Binder of Doom was a nondescript black binder about three inches thick. It had no cover page and no markings: I didn't want anyone to realize the secrets that were in it. I carried it around with me everywhere. I slept with it in bed with me. That's how terrified I was these secrets would come out.
Then the Binder of Doom got worse. Having completed my survey, I now devised attacks on the system. I found ways enterprising individuals could fleece the company out of truly mind-boggling sums, and how difficult it would be to detect these attacks with the then-current security infrastructure. By the end of six months the Binder of Doom was stuffed to bursting and I was giving serious thought to filing for a concealed-carry permit. I wondered if the sheriff's department would understand if I told them I was routinely carrying around a binder with a *conservative* worth to a criminal syndicate of $100 million.
I went back to my manager. I told her I was done. It was time to remediate the risks. "Oh, excellent," she told me, "because we just ran out of money for the remediation."
Uh. What?
"Management has decided the main risk is in unsecured communications links, so just ensure we're using PGP on everything and we'll call it good."
I asked if she wanted the Binder of Doom.
"No, you hold onto it for a while."
So I became increasingly disgruntled, bitter, and sarcastic. I told everyone I worked with that I'd been retasked to "secure" our network using PGP -- and even old-school PGP 2.6, not GnuPG (which had just reached 1.0), either -- and oh God this is awful and if this company lasts another year it'll be a miracle and...
I was shortly thereafter cashiered for having a toxic attitude towards work. I walked into the parking lot, got into my car, and tossed the Binder of Doom into the passenger seat. As I drove away I realized something was horribly wrong, but didn't realize what until I was pulling out of the lot:
I HAD THE BINDER OF DOOM IN MY PASSENGER SEAT.
I returned to the office and tried to walk inside, but was met by an HR rep at the door who told me if I didn't leave they'd call the police and file a trespass charge. I held up the Binder of Doom to the HR rep. "Do you want this back?" I asked.
"No," she told me clearly. "Keep it. We just want you to leave."
I turned around, gobsmacked, and left the company holding detailed plans for how to embezzle $100 million or more... which the company had just thoughtfully delivered into the hands of a disgruntled former employee.
(And if you're wondering what I did with the Binder of Doom, it sat on my bookshelf for a few days tempting me before I threw it into an incinerator and threw the ashes into a strong wind.)
Most folks, including many so-called "experts", lack both the knowledge and ability to do anything close to a "real" security check. So the best route is to rely on "canned" testing that has been created and is maintained by a reputable group.
First, scan the platform (with the application installed) for known vulnerabilities, including updates, configuration (CVRs, STIGs), rootkits and antivirus.
Second, scan the source code with all available static analysis tools. Start with lint, then do as many more as you can afford.
Third, do as much run-time testing as the schedule permits, being sure to do not only functional testing, but also fuzzing at all levels.
Do the above using Free/Open tools, but also be sure to check out commercial tools. Yes, some tools are very much worth paying for.
That will get you 99% of the way there, with minimal time and effort invested.
A different group was working a new product. Software does nothing terribly exotic yet quite expansive. Data driven jobber managing about two thousand tables. Mostly boring busywork.
Tried to talk some sense and give advice early on in the process yet they just took off coding each bit at a time with no strategy to produce a maintainable product or manage the accumulation of complexity. It seems the lead couldn't get image of me as punk kid who doesn't know jack out of his head no matter how diplomatic I tried to be. This guy wears Einstein shirts to work and quantum physics is assured to come up in any conversation lasting more than 10 minutes.
From the brain-dead workflow alone and insane amount of cut and paste work being checked into version control it was obvious early on what the likely outcome would be.
8 months go by and the team declares software ready for production use. QA quickly signs off on it. After getting over shock of QA signoff I get down to doing QA's job for them. In the span of an hour logged over 20 critical show stoppers most of them security related. Things only get progressively worse from there. When all was said and done nothing they did was even worth salvaging and they all would be shown the door within a months time.
To provide some context forget about things like coherent use of cryptography, strong authentication or anything more than a rudimentary access control scheme. Redress, CSRF, secure flags, DOS/brute force mitigation... none of it even in scope for this project.
I quickly discovered how to invoke the setup configuration without any authentication, steal credentials and overwrite any file I wanted on the server. Then I discovered how to bypass authentication altogether to access anything. Next comes torrents of XSS/SQLi and security bypass of the basic as hell access control system they haphazardly implemented.
From the angry tones impossible not to overhear some of the people on that team hated me after that interpreting what I did as an attack on them personally. While I did try early on to explain better approaches I quickly gave up. Mostly for personality reasons... Mr Einstein's personality was so over the top I really lost interest and had plenty of my own work to get done.
My takeaway from the ordeal is a reinforcement of simple or die principal. If a domain is so difficult that it is helped by manual reviews of others then you have already failed long before a single line of code was ever written.
If the team had listened and approached the problem in a more aspect oriented manner virtually ALL of the security problems in this admittedly trivial piece of software would either have not been POSSIBLE or worst case globally addressable. The only path to success the only possible path available in my view is designing systems in a manner where failure is extraordinarily difficult to achieve.
Success requires more thinking than typing and more planning than modern day code mill optimized methodologies allow.
I worked at a place where we had a lot of disk (~2TB) with data that were accessible to the public. We also had a web site in place where users could upload new data, which would then be vetted by staff and then published to the public. This was all okay.
The bad part starts when we hired a new guy who, among other duties, wound up redoing the upload interface. So he redesigns and implements the system. I wasn't part of that process, and I wasn't paying any attention to how he was doing it. Later on, he quit, and his codebase was passed to me to maintain. That's when I started looking at the code and discovered that he had implemented a server-side API for uploading data that required no credentials whatsoever--he had set up a password authentication on the web front-end, but the API itself was open to the world. Oh, and the new API also stored uploaded data directly in the publicly accessible disk space. Any rando on the Internet who discovered this API would be able to upload hundreds of GB of whatever porn and warez they wanted, and just pass the URLs out freely. This code had been running in production for months.
Luckily, apparently nobody noticed. I audited the file system and its contents were exactly the files we expected to be there, and with the correct hashes. But it all made me wish we had a better review process, if this was the kind of coder they were going to hire.
In 2013 they all reinstated the warnings because the heuristics kept telling them you hadn't stopped being an aggressive, unstable dick.
Work smart, not hard!
I work for a pretty big bank with thousands and thousands of servers. I doubt 10% would pass a PCI audit, but since there are so many incompetent and non technical people between the assessor and those that know what they are doing.
I've heard the manager of Sys admins say "I've never been told any of our servers fall under PCI" this specifically in reference to systems that comb over CC use in search of fraud......
Shared system accounts running processes with full sudo access using a password forced using the crypt, passwords in a script in plane text and hasn't been changed in 10+ years...
A lead Unix Architect who says N/A to PCI/CIS/Security requirements because he wants to.
And an infosec, dispute being shown, don't understand and just wants to pass their Security+ exam....
And things get much much worse, makes me want to update my resume....
The spirit of resistance to government is so valuable on certain occasions that I wish it to be always kept alive
When does a user need to launch a specified path, when that user is not responsible for all of the code run on that OS instance?
An educational environment?
Or are we talking about low level IT staff working with a fudged together fix for something or other?
I beg your pardon.
I buy an antivirus because it half-works. And that half-works is enough to alert me to bigger problems, and usually minimize or stop the spread of any infection on the network. It literally is better than nothing, outside of a truly closed system.
Standing security guard on an operation involving [can neither confirm nor deny] during an inspection. One of the inspectors was standing outside the security area next to some pipes that ran along the bulkhead. He put his hand on them and slowly started inching it along them towards the plane defined by the ropes that marked the security area. When his hand was just short of breaking the plane, I took my nightstick out and laid the tip on the pipe just touching his fingertips. He took his hand back, made a note and stepped back. There was a positive comment in the final report "during inspection of the [can neither confirm nor deny] operations the security guards were notably alert and forehanded* in the conduct of their duties".
Then there was time a bomb threat was called away* and I found an "officer" wandering around unescorted. (During security situations we were supposed to pair up.) My partner and I had to forcibly and bodily haul him to the wardroom. (We didn't actually have to take our nightsticks to him, but it was close.) Turned out he was an officer who had just reported aboard and his escort had abandoned him. Got chewed out by the COB for manhandling an officer. Got congratulated by the XO for alert and proper handling of the situation. The escort who bailed went to mast and lost a stripe and half his pay for thirty days. The officer hated me until he learned the truth of how such situations were supposed to be handled. (That is, exactly as I handled it.) When he later became my division officer, he'd frequently bypass the chief (who was an idiot anyhow) and seek out my advice.
Also got chewed out by the COB for taking charge at the scene of a another security drill... He'd wanted to see how the guy sitting next to me would react. I just told him piss off, I was there and trained specifically to handle that situation and the guy next to me wasn't. If he wanted to see how guys with less specific training would react he shouldn't have done what he did in front of a guy who was. Not my fault he wasn't paying attention.
* Navy speak for what we now call "being proactive".
** It was a drill, but we didn't know that and anyhow regulations required us to treat all drills as real unless informed otherwise.
I'm agreeing with the parent. Perhaps the system was surrounded by reinforced physical barriers, but what kind of device security was in place?
How long before somebody engineered an input device to feed malware to the machine or elevate the privileges?
How many people had access to the physical machine for maintenance if nothing else?
If it that secure, either you have to lock down the network to only allow traffic to a specific IP. Or be absolutely 100% sure you can trust everybody that enters that room.
Some years earlier, though, I had a job doing B2 security auditing at Data General. For those of you who don't remember Data General, they had their own line of high end workstations and their own variant of UNIX. Their thing was making secure versions of UNIX and they wanted a B2 cert for it. So I got to read a good chunk of the original AT&T C standard library, which they'd licensed. We'd look for functions that could have unexpected side effects, write tests to prove side effects were or were not occurring for each function and wrote a little report for each function in the library. Those reports were eventually bundled up and set off to the NSA.
The Ping of Death exploit for windows came out around that time, and it turns out that receiving the ping of death would NOT crash Data General's UNIX, but that originating one would. After we got done with the C library, we started looking at utilities. I got telnetd and found that a buffer that could receive environment variables from the remote side had a hard-coded size and could be exploited for a remote root buffer overflow attack. Couple years later the same exploit was discovered in the Linux telnetd. I'd thought about checking but by then telnetd wasn't enabled by default, and I thought the Linux telnetd source probably was developed somewhere other than AT&T and may not have even had the same bug in it. Oh well, you win some you lose some.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
It literally is better than nothing, outside of a truly closed system.
Tell that to my first Windows computer that picked up the relatively benign Lemming virus: http://wiw.org/~meta/vsum/view...
It had been known for at least 2 years when the virus checker completely missed it, then opened (and hence infected) every COM and EXE file on the computer.
Despite having no payload, the thing was so fragmented afterwards I had to format and reinstall (which is the thing to do anyway, but it made backing up any data bloody difficult)
Virus scanners are like condoms; you suggest everyone use them because you can't stop their behaviour so you hope to mitigate it.
I think the biggest issue is decryption. You have to be able to find a balance between encryption and decryption performance at the client level, and an impossibly high level of compute cycles required to decrypt the contents without the "key" to insert into the algorithm. I imagine it is also a good idea to secure the algorithm as well.
Then there is also the matter of getting your clients to trust you regarding your algorithm and encryption technology, to not have a back door or exploit.
I buy an antivirus because it half-works. And that half-works is enough to alert me to bigger problems, and usually minimize or stop the spread of any infection on the network.
And you right there are spouting marketing FUD.
Antivirus makes your computer less secure. Do a search for "antivirus vuln."
"First they came for the slanderers and i said nothing."
I joined a development team while they were just finishing a security audit. The position actually opened up because they fired a previous employee just after the audit started. Of course, I snooped around to find out why. So this company developed a fairly popular communications software and one of the main features they touted was their encrypted communications. After poking through their recent svn commits and inspecting the changes, I quickly found out that the fired employee had changed their top-level CA verification to accept ANY certificate, except to fail two specific CAs (more on this later)... this basically meant that their entire encryption model could be spoofed, even by self-signed certificates. The odd thing was that this shop had good practices, CI, quality Unit Tests, a good QA team with thoroughly documented procedures... so I looked at the Unit Tests and realized the one of the two hard-coded CA failures was for the specific CA being used by the Unit Test to validate the bad CA failure case. Ok... so what is the other hard-coded failure CA? Took me a while to find out, but it turns out that it was the CA being used by the QA department to hand test the CA failure case.
TLDR; Fired employee maliciously broke their CA checks and took steps to hide it from the Unit Tests and QA.
Everything is a vulnerability. An antivirus application is better than nothing.
There are more secure solutions than anti-virus software, but security must be traded for usability.
An antivirus allows for the greatest level of usability by a user, without foregoing all security altogether.
So why the fuck aren't you using Rust?
"Whooooooooooooooooosh" times ten to the 300th power.
That went so far over your head, it's probably in low-Earth orbit.
Just cruising through this digital world at 33 1/3 rpm...
Like rust?
If I had mod points, they'd be yours.
Just cruising through this digital world at 33 1/3 rpm...
Through a client referral, I was introduced to a company that was in sudden need of a new web host. Their current Australian host was shutting down, and they had two weeks (by the time I was referred) to move their small Canadian site elsewhere.
When I say "small Canadian site", I mean the site was a small, promotional, site, with little more than five pages and a signup form.
Little did I know...
This was ultimately the consumer-brand of a large telecom provider -- a very large, national, telecom provider. This "small" site, was a mass-market allowing consumers to sign-up, and to also pay their monthly long-distance bill. This was circa 2010.
We shook hands, I said: "sure, I can move your site in the two weeks, just give me the credentials to it, and I'll figure it out."
Wow was that a mistake. Anyone heard of CakePHP?. I had to figure it out pretty fast.
It was late one evening, when I discovered the page that allowed customers to pay their bill online -- something no one had told me was a part of this tiny site. There was no https/ssl to even hint at it. And then I saw the MySQL insert statement, and the variable "card_number". And I was scared.
I said, to myself, "no, it can't be!" There must be some part of the platform wrapping the database call that must mask-out the card number. Or this must not be the actual card number. Or maybe it's not used anymore. Or something.
Then I logged into the phpMyAdmin, with the credentials given to me.
So, this is when you need to understand something. I'm a small independent web developer. At the time, I was teeny tiny. I had no written contract. The e-mailed and in-person job discussions said nothing of sensitive information of any kind. No money would be transferred until the job was done. So at this point, there is effectively zero legal agreement between us.
I looked at the table, I saw over forty-thousand records, each with real, live, credit card numbers. . .and expiry dates, and card holder names, and purchase amounts, and confirmation/approval codes.
I was stunned.
Obviously, being the non-criminal that I was at the time, I told them. I told them that I was appalled. I told them that it can't stay this way. I told them that I was going to charge them a few hundred dollars to encrypt the field, and the very least -- I was too young to know that I should have been charging way more.
They said they didn't care, I should just leave it as-is.
That was over a decade ago. Ever since then, I've learned that there are very few clients who will pay five cents towards security, backup, or encryption of any kind. In my entire 25-year career (so far), I've met only two clients who'll invest in that kind of safety.
So I no longer bother even suggesting that security or backup is a good idea. My legal contracts ensure that I'm not legally liable for the consequences of doing anything that they've explicitly told me to do, and that's good enough for me, I guess.
So to all those youngin's not yet jaded for failed efforts to be good, enjoy having the hero-skills to save people; but if your career is anything like mine, you'll quickly learn that those skills carry a perfectly zero-dollar value.
In the days of Equifax, riddle me this: where's the law that says you can't store millions of archived data all in one place, forever, online? Some of these 40'000 records hadn't been charged in over a year -- clearly old/former customers. And aside from those from the current day, all of them were old records that were no longer needed at all. Equifax had e-mails from ten years ago. How about a very simple law saying that things get taken offline eventually? Your ten-year-old e-mail can be accessible from that machine in the corner of the office, or through a request for the tape backup, and that's good enough 99% of the time.
But hey, where's the law that says one model of gun is illegal.
Thanks for the freedom.
Everything is a vulnerability.
Now you're just making up shit because you know you're wrong. A better argument would have been if you built a metric to figure out how much more safe you are with antivirus than without. But you didn't do that, because the answer is less safe.
"First they came for the slanderers and i said nothing."
A metric to determine how much more safe one is with an antivirus than without?
An anti-virus conducts inspections of code on the file system.
Saying one is better off without an antivirus because it may introduce a vulnerability is akin to saying public restaraunts are better off without health inspectors, because the inspector might be a thief.
The reality is that your argument merely demonstrates that it is foolish to ONLY have an antivirus, and no other failsafes or redundancies should the antivirus fail. An antivirus is a tool, not a magic bullet.
Again, you are reaching for propaganda because you lack understanding.
Because you are nice, I will teach you a logic lesson here. You have made several arguments by analogy here, but they are wrong: an argument by analogy needs two parts. The first is the analogy, and the second is an explanation that the analogy matches this situation.
I can show you why by giving you my own analogy: an antivirus is like poison: it brings vulnerabilities to your system that weren't there before, some of them very severe. So which analogy is right? Yours or mine?
"First they came for the slanderers and i said nothing."
You are totally delusional Chris.
Please explain to me why the submission you made in 1 account appears in all following accounts:
https://slashdot.org/~IAteFatC...
https://slashdot.org/~IHateFat...
https://slashdot.org/~ILoveFat...
https://slashdot.org/~cdreimer
The unique submission link is:
https://slashdot.org/submissio...
Everything I write is lies, read between the lines.
People will tell you that, with rules requiring password to have upper and lower case, digits and a special character are "best practice"
Since I sit on the other end (the receiving end of these jokes here), i.e. doing penetration tests, code reviews and general consultation in the area of IT security, I might be able to answer this.
Usually we get called when someone either wants to or (more often) is legally or contractually obligated to perform security reviews of their code, their processes or their remotely accessible infrastructure, e.g. webservers. Then we throw everything (or not, depending on what they want) we have in our arsenal of security shit against their stuff and look what sticks.
And in the end, we usually sit there with their managers and (far too rarely) with their developers and server admins to discuss what we found and how they could fix it.
My guess is that this is about the ... let's say less palatable specimens of my business, the haughty security know-it-all who berates you like a little child for not knowing some esoteric once-in-a-blue-moon-possible race condition, the secretive "I-can't-tell-you-how-I-did-it" asshole who still demands that you fix what he won't tell you about, i.e. expects you to find the error yourself and of course the "my-way-or-the-highway" idiot who insists that his approach to solving a system is the only permissible one.
But don't worry, assholes sit on both sides of the table. My favorite is the "but this is impossible" admin, refusing to accept that his configuration could even possibly have some flaw despite you just demonstrated it to him.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Doesn't work if your CISO knows his shit. Ours would drag your ass out of your current project and give you the "fix that! NOW!" lecture. Not necessarily with more words but with more decibel.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
You jest, but that's what we did.
Very similar setup, a completely isolated network with no way to bring data in an automated way into it. Data was entered manually only and extracted on CD-Roms. Similar problem, getting any kind of data line in would have required unacceptable security breaches. And similar requirements, i.e. all machines need antivirus software.
So we wrote one. What that software basically did was to routinely check all hashes of all files on the machine (with the exception of the data files that contained text-only and some system files that didn't want to play nice) and locked the machine if they found a single file that did not match the whitelist.
A "signature update" was basically us recalculating the hashes whenever a planned change occurred on a machine. Since that happened with a frequency of about once a month (i.e. at MS patchday) and we had mostly identical machines, that was not really a big deal. We simply created a "template" machine, patched it, created the hashes and rolled them out to the other machines along with the patches.
In other words, we reduced the problem of "you have to have an AV" to what the AV is supposed to do: Ensure that nothing bad exists on the computer. Since our approach was more restrictive than the required one (i.e. nothing unknown allowed at all instead of nothing bad allowed), it was considered acceptable.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Why?
I mean, yes, I can, but why would I? More, why would I trust a routine I wrote more than one that has, by its very nature, survived countless security reviews from countless security researchers and specialists?
Your routine is as secure as you are. Commonly used ones are as secure as the security community can make them.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
If you allow changing of the hardware, then the term "isolated system" loses all meaning. Feel free to do so, but know that your statements become nonsense if you do this.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Process management fail.
Second question should be "If Yes, are you using the company standard X building block OR is your job to redesign the standard X building block?"
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Wow. Just wow.
Who did these bullshit requirements come from?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
The CIO's "policy is two factor authentication -- all APIs require a username and password"
I guess that's the IT version of "we have both kinds of music - country AND western".
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
This story never happened.
Hardware fails. Even new hardware. That is why we have "warranties", because there is a period of time where most hardware does not fail, but some outliers do.
Service to the physical components may be minimal, but is still a necessity. The two most likely to fail being the hard drive and power supply.
Presumably the PC in the isolated environment is in a clean room, so dust caking the cooling fans isn't a concern. RAM would be expected to be a high quality, and last the life of the PC.
Hard Drives seem to have a shorter lifespan than any other component. Four to ten years is what I've seen. Presumably the isolated equipment will have redundancies. Such as RAID 1+0. Those drives will need to be monitored and replaced. Which will have to be done by sight on an isolated system.
"Common sense" is just a term that means "agrees with what I already think."
The Quirkz Handbook of Self-Improvement for People Who Are Already Pretty Okay
Oh that makes me so happy. Not only did you work around the problems created by bad bureaucracy, but you ended up making something really great. If there were a Diogenes looking for a man who cared about security, he could rest when he found you.
"First they came for the slanderers and i said nothing."
Cattle prods, loading skiffs... But with Houston as well, probably a gun nut. ;)
Lol! Fair point!
These aren't "oh, I'm a sys admin and need to log into this machine!" passwords, these are automated process passwords. They can be long and crazy difficult because you will never type them.
My last job had a terrible time of this, people were always adding random jobs that did things using an admin password ( Instead of a proper account), then wondering why it exploded when we changed the admin password bi monthly.
But then nobody gets the free meeting Panera takeout lunch...
Why are you even using passwords when public key authentication is a thing?
Wow, someone is still taking this seriously???
It's a pretty accurate depiction of an encounter with a typical Rust flake if you ask me.