An Interview With an Anonymous Amazonian (logicmag.io) 201
Logic magazine has interviewed an anonymous engineer at Amazon Web Services. An excerpt from the story, which touches a wide-range of topics including controversial work with the military and police and takes on other cloud providers: So when you use AWS, part of what you're paying for is security.
Right; it's part of what we sell. Let's say a prospective customer comes to AWS. They say, "I like pay-as-you-go pricing. Tell me more about that." We say, "Okay, here's how much you can use at peak capacity. Here are the savings we can see in your case." Then the company says, "How do I know that I'm secure on AWS?" And this is where the heat turns up. This is where we get them. We say, "Well, let's take a look at what you're doing right now and see if we can offer a comparable level of security." So they tell us about the setup of their data centers. We say, "Oh my! It seems like we have level five security and your data center has level three security. Are you really comfortable staying where you are?" The customer figures, not only am I going to save money by going with AWS, I also just became aware that I'm not nearly as secure as I thought. Plus, we make it easy to migrate and difficult to leave. If you have a ton of data in your data center and you want to move it to AWS but you don't want to send it over the internet, we'll send an eighteen-wheeler to you filled with hard drives, plug it into your data center with a fiber optic cable, and then drive it across the country to us after loading it up with your data.
What? How do you do that?
We have a product called Snowmobile. It's a gas-guzzling truck. There are no public pictures of the inside, but it's pretty cool. It's like a modular datacenter on wheels. And customers rightly expect that if they load a truck with all their data, they want security for that truck. So there's an armed guard in it at all times. It's a pretty easy sell. If a customer looks at that option, they say, yeah, of course I want the giant truck and the guy with a gun to move my data, not some crappy system that I develop on my own.
Right; it's part of what we sell. Let's say a prospective customer comes to AWS. They say, "I like pay-as-you-go pricing. Tell me more about that." We say, "Okay, here's how much you can use at peak capacity. Here are the savings we can see in your case." Then the company says, "How do I know that I'm secure on AWS?" And this is where the heat turns up. This is where we get them. We say, "Well, let's take a look at what you're doing right now and see if we can offer a comparable level of security." So they tell us about the setup of their data centers. We say, "Oh my! It seems like we have level five security and your data center has level three security. Are you really comfortable staying where you are?" The customer figures, not only am I going to save money by going with AWS, I also just became aware that I'm not nearly as secure as I thought. Plus, we make it easy to migrate and difficult to leave. If you have a ton of data in your data center and you want to move it to AWS but you don't want to send it over the internet, we'll send an eighteen-wheeler to you filled with hard drives, plug it into your data center with a fiber optic cable, and then drive it across the country to us after loading it up with your data.
What? How do you do that?
We have a product called Snowmobile. It's a gas-guzzling truck. There are no public pictures of the inside, but it's pretty cool. It's like a modular datacenter on wheels. And customers rightly expect that if they load a truck with all their data, they want security for that truck. So there's an armed guard in it at all times. It's a pretty easy sell. If a customer looks at that option, they say, yeah, of course I want the giant truck and the guy with a gun to move my data, not some crappy system that I develop on my own.
Amazonian is someone from the river. (Score:2)
And a short explosion of a bomb made out of pure Rockefeller won't change that.
Security vs. Asset Value (Score:4, Insightful)
Re:Security vs. Asset Value (Score:5, Insightful)
So I don't think "AWS is more secure" is the entire picture.
Well not only that, but I'd argue it's a bit misleading. If you're going to sell security as a feature, I think you should protect the users from themselves as well as just offer constantly patched virtual servers. But how many times have we read about some sensitive dataset being exposed on AWS because the dataset's owner didn't properly lock it down?
Rather than default being a somewhat open system, the default should be to completely wall it off. Require active steps be taken to open anything up.
Note that I am not blaming Amazon for the breaches - in the end, the owner of the data is responsible.
Re:Security vs. Asset Value (Score:5, Informative)
But how many times have we read about some sensitive dataset being exposed on AWS because the dataset's owner didn't properly lock it down?
Amazon fixed that and now you get multiple notifications if you have a bucket with public access. There are Inspector rules to detect such buckets within an organization and you can even block entire organization units from even making such buckets.
Re:Security vs. Asset Value (Score:5, Insightful)
Actually secure is the default. You need to make the effort to make an S3 bucket available. The stories you hear about unsecured S3 buckets being exploited were deliberately made public, the warnings about the possible repercussions of that decision were ignored, and then they were left that way.
Re:Security vs. Asset Value (Score:4, Informative)
Actually secure is the default. You need to make the effort to make an S3 bucket available. The stories you hear about unsecured S3 buckets being exploited were deliberately made public, the warnings about the possible repercussions of that decision were ignored, and then they were left that way.
That's not the whole picture, since useless is also the default. When trying to access assets in S3 with HTTP, everything is inaccessible to every server. So the possible configurations, ordered by effort, are: 1) trivially secure / useless, 2) fully public / insecure, 3) secure with access policies attached and/or users created for the purpose of access.
So if you don't count the trivially secure default state (akin to a server that is turned off being perfectly secure), much more effort is needed to secure a S3 bucket than to leave it unsecured. When the bucket is created or populated, there is no quick option that allows decent permissive security such as a checkbox that says "allow access only from servers in this organization".
Re:Security vs. Asset Value (Score:4, Interesting)
Too bad it wasn't the FP. It's a good comment that quickly goes to the heart of the matter. Well, one aspect of the matter at hand.
However, my own initial interest is in two other aspects. (I always seem to have a "however" and a couple of "buts"...)
(1) Is the "anonymous" sourcing just a publicity stunt by Amazon? This might be a carefully calibrated pseudo-leak designed to appeal to certain potential customers. I can even see how it could be deliberately targeted at people with certain kinds of paranoia. Perhaps even counting on Slashdot and similar websites to mountainize the molehill?
(2) Amazon understands the value of certain kinds of data. I strongly suspect that the high-value data includes our personal data, which will NEVER leave Amazon. At least not if Jeff has anything to say about it. This may lead to a recursive call on (1) in terms of figuring out who to target with publicity stunts.
But mostly I would concur and describe the secure van as a twisted joke. Security is a chain, and the attackers are always going to look for the weakest link. Even if the import capability is perfectly secure (and I don't believe that), then the data is worthless unless you have access to it. If access exists for you, then it exists for the attackers, too.
In conclusion, I stopped doing business with Amazon many years ago. I smelled a rat, and the smell has only grown stronger since then and even though I've tried to increase my personal distance to the maximum. Brainphishing and brain hacking and corporate cancers all stink.
Re:Security vs. Asset Value (Score:5, Informative)
I currently work at Amazon Corporate, after 5 years in the AWS SOC. I helped design and then implemented the physical security on the Snowmobile, it was an interesting project. The trailer is taken to the customer site and parked in a secure area (that's part of the system requirements), there needs to be camera monitoring of the area 24x7 (one customer had to hire extra temp guards). Fiber is run from the customer's network backbone to a switch on the inside of the Snowmobile with some sort of continuity monitor. There are motion detectors, IRBs and cameras recording inside the Snowmobile with continual live connections (with backups) to the AWS SOC, and the SOC has contact information for the customer's on-site security with documented procedures for the various alarm types. Only a few AWS blue badges have access to the reader allowing access, and they need to call the AWS SOC to have the internal monitoring turned off before entering. Now it's up to the customer to load their data, the first customer broke their backup tape library twice pumping all that data into the Snowmobile.
I won't talk about the transportation except to say that the truck driver has a special clearance, its location and internal state is constantly monitored, and as TFS mentions there is an armed guard.
When it arrives at the AWS site where the data is to be ingested the same protocols apply as at the customer site, until it has all been saved, at which point the drives are security wiped. There are multiple security measures on the network communications, the storage drives, the controllers, etc. which I know nothing about except that they exist.
Does the Snowmobile still sound like a joke?
Re: (Score:2)
Does the Snowmobile still sound like a joke?
Well, sorry but it does. All of this is for show, as you can simply encrypt and then send it over internet. There is no known way to break AES as long as you keep below max archive size per key size. If you are extra paranoid, also send encrypted archive over IPSEC tunnel with PSK. If you are extra, extra, extra paranoid and sending nuclear lunch codes, do all of this over dedicated line.
This reminds me of a time long ago a large bank had to send me its encrypted database. Back when computing was done by b
Re: (Score:3)
I know that my part of the project was as well executed as was possible. I can't speak for the rest of the chain except to say that the people involved in each are some of the best in the business and the Technical Project Managers assigned to these transfers are top-knotch. IMONSHO the weakest link is most likely to be on the customer side.
Re: (Score:2)
I'm sure it's encrypted as it is written int the RAID array, that's standard practice with sensitive data even in the data centers.
Re: (Score:2)
I wonder if I have a criminal mindset? It seems obvious to me that the first place to attack is at the customer's end where the data has to be created and accessed.
Or simply show up a day early with a different similarly-looking truck and tell them that it is too heavy load to transport encrypted. Assuming unlimited resources for the attack, spoofing identity of a truck is easier than spoofing identity of an endpoint.
Re: (Score:3)
You've never copied exabytes of data I take it, very few people in the world have. You don't just "show up a day early" and pull out that evening, it takes weeks to load the Snowmobile, or months depending on the limits of the customer's data storage system.
Re: (Score:2)
Indeed. AWS is a big fat target. Unless the attackers have their own critical services on it. But it is wayyyy softer a target than a lot of different data-centers that need to be attacked individually. AWS is also a pretty defenseless target against some nation states that can just make a law saying "give us access to everything or go to jail".
The cloud is a hype. There are very little rational reasons to move things to it. And those that do become dumber and dumber with regards to operating their own infr
Re:Security vs. Asset Value (Score:5, Informative)
a pretty defenseless target against some nation states that can just make a law saying "give us access to everything or go to jail".
Amazon spent a gigantic pile of money building a state of the art data center in the Chinese interior, with assurances of independence and protection from unwarranted intrusion. When the DC was almost complete they changed their tune and said that AWS would have to provide access on demand. They ended up selling the DC at a loss rather than acquiesce, I believe it's now mining Bitcoin.
Re: Security vs. Asset Value (Score:2)
Re: (Score:2)
There are very little rational reasons to move things to it.
Well, not exactly. If you can't afford the expense and good expertise to set up and maintain a data center but need one, the cloud is one hell of a bargain.
Re: Security vs. Asset Value (Score:2)
Using cloud services is really putting all your eggs in one basket - for the entire world.
Assume there's a major internet or power outage that is impacting the services but your local business could still run if it had the data locally. Everything is on the shelves ready to sell but your data is inaccessible so you can't sell.
And if this goes on long enough - what would the local tax authorities do? In the EU there's the VAT declaration that has to be done monthly, and if you fail it you are screwed. Nobody
Break them up (Score:5, Insightful)
From the article, a direct admission of acting as an illegal trust:
One of the reasons why the antitrust people are looking at Amazon is because Amazon is using highly profitable businesses where it has a really durable advantage in order to subsidize losses in other divisions that it uses to capture market share. Without an organ similar to AWS, a competitor like Walmart has to lower prices below the level of profitability to remain competitive. And they can only sustain those losses for so long.
Re: (Score:2)
Loss leading is not a trust, it's a strategy. You can do it with any money source.
It's generally only illegal if done with state aid, ie. dumping.
Re: (Score:3)
To add to that, in fact loss leading from a market perspective is an anti-trust measure ... there is no other way to displace entrenched monopolies.
Apple massively cross subsidizes as well to displace and build new monopolies, any competitor will have to take massive up front losses to displace them as well.
Re: (Score:2)
Well then, break up Apple too.
Re: (Score:2)
I don't disagree.
Re: (Score:3)
Why not change the rules of the game so the giant companies want to break themselves up? The trick would be to link retained earnings to smaller market share. This could even rely upon the competitors to help figure out what the market is and who has what share of the market.
But I still feel the main reason to make the corporate cancers smaller is so that the government can be smaller. "Too big to fail" is the most dangerous kind of lie. Loss minimization is a secondary benefit.
Re: Break them up (Score:2)
It was considered with Microsoft but it never happened. Whenever things like that happens it's usually too late in the tech industry and the break-up is not helping.
Re:Break them up (Score:5, Informative)
You're wrong [ftc.gov] that it doesn't apply to antitrust law in the US.
Pricing below your own costs is also not a violation of the law unless it is part of a strategy to eliminate competitors, and when that strategy has a dangerous probability of creating a monopoly for the discounting firm so that it can raise prices far into the future and recoup its losses.
And that is EXACTLY what Amazon does.
Re:Break them up (Score:4, Insightful)
You have no clue if this statement is accurate or not since Amazon does not release numbers like that externally. And it is also unlikely that the employee in the article has access to this level of accounting detail. It is extremely easy for a division of a business to be operating at a loss - it happens almost all of the time when a business is rapidly growing like Amazon. Operating at a loss is not an antitrust violation, the antitrust measurement is pricing below your variable costs - not your total costs.
Lets say Amazon opened ten new warehouses and bought 20,000 new electric delivery trucks this year. For sure that would cause them to operate a loss this year. But they would not be operating at a loss compared to variable costs since warehouses and delivery trucks are capital expenditures. As long as Amazon keeps growing rapidly they will operate at a loss every year until they slow down. Maybe next year they'll buy 25 new jets and have another loss. Losses from R&D into drone delivery also don't count. It is perfectly allowable to use profits from another division to fund these types of capital expenses.
What would be illegal is to run a consistent loss on the daily delivery of packages. Add up the labor, fuel, wear and tear, insurance, etc needed to deliver a package. Amazon better be charging more than that total to deliver it. Doing daily delivery at a consistent loss for competitive purposes would be an antitrust violation. Of course the Post Office can't seem to deliver packages at a profit but those loses are not being done for competitive purpose, instead those losses have to do with inefficiencies in the way the Post Office is run.
Amazon is simply fueling their capital consumption using profits from AWS. That is really no different than issuing stock and letting investors supply the capital.
Rather interesting, actually (Score:4, Informative)
My favorite bit:
Re: (Score:2)
Other highlights were "Prime Video is a loss leader for Jeff’s sex life," what appears to be a plan to become the USPS' roommate and landlord(!?) and the description of the 3-point revolving door between the Pentagon, GAO, and big vendors like Amazon.
Re: (Score:2)
Honestly, it's "things we knew, confirmed in a rather hilariously blunt way" more than any kind of news.
I have to say that I do like this source. Whoever ends their thoughts on things being good or bad with "maybe I am a bad man" while being this blunt on many topics is probably not a bad man.
Armed guards? LOL (Score:4, Interesting)
You know what's cheaper and better than an armed guard? Full-disk encryption.
Re:Armed guards? LOL (Score:5, Insightful)
You know what's cheaper and better than an armed guard? Full-disk encryption.
Tell me your encryption key... or I'll shoot you.
Re:Armed guards? LOL (Score:5, Funny)
Many years ago, a co-worker almost didn't get his security clearance after being asked: ``If you were working late at night and several people armed with automatic weapons broke in and demanded to know where the secret documents were kept... what would you do?'' His response of ``I'd ask `Will you need any help loading them into the truck?' '' was not what the interviewer was looking for. But it was probably the best practical answer anyone ever gave in response to that question.
Re: (Score:2)
I mean, ask a stupid question...
Re: (Score:2)
Seems like a smart question. Are you going to cost the company millions in damages to the family of the dead, outgunned guard?
Or, like every other business, should the guard preserve their life when ambushed and clearly outmatched?
Every retail business and bank out there tells their employees to cooperate and not act the hero (beyond, say, hitting the silent alarm).
Re: (Score:2)
Exactly. Almost everyone would answer that kind of question in essentially the same way if they were being honest. Someone who says they'd play the hero is probably either lying or the kind of slightly screwed up rambo personality you really don't want in that kind of situation anyway. Obviously there are some exceptions, but they probably aren't going to involve a civilian security guard working solo late at night.
Re: (Score:2)
I mean, it truly depends on what was in those documents. Like, will they enable these armed assailants to start WWIII by launching all the US's ICBMs? Then I can see getting shot. If the secrets are next months marketing plans? Nope. It's the same reason why the "carry a gun" to prevent mugging plans are stupid. Are you really going to risk your life over $50 and some credit cards they'll FedEx replacements of?
Or is this supposed to be one of those lateral thinking answers: "I would stay behind my bul
Re: (Score:3)
Like, will they enable these armed assailants to start WWIII by launching all the US's ICBMs? Then I can see getting shot.
Right, but let's hope that would fall under the "probably aren't going to involve a civilian security guard working solo late at night" part of my previous comment!
Re: (Score:2)
One would hope! But it wouldn't surprise me if there was something in a private defense contractors files that would be useful for such a purpose.
Re: Armed guards? LOL (Score:2)
Storing all secret documents in a single location is also a problem. Single point of failure.
Losing the access to documents can harm a company more than revealing the contents. Consider this when putting your data in the cloud - the cloud provider will have your company by the balls.
Re:Armed guards? LOL (Score:5, Insightful)
But I'm just a truck driver, only some guy in an office in Seattle knows!
Re: Obligatory XKCD (Score:2)
Or send a trojan application into his/her computer. That's what happens most frequently.
Re: (Score:2)
You know what's cheaper and better than an armed guard? Full-disk encryption.
If the new AWS customer has so much data they justify the come-get-my-shit-with-a-truck migration plan, then they're probably already using full-disk encryption.
And additional security beyond that entirely depends on the value and if you can afford to even have your encrypted data stolen. History has proven that cracking encryption often breaks down to the simplistic matter of resources and time.
Re:Armed guards? LOL (Score:4, Insightful)
The armed guard is great. He makes sure that you get to keep your data and someone else doesn't just take it away (granted they can't read it, but you probably wanted it to arrive at its destination).
Both things are useful and they solve different problems.
Re: (Score:2)
Seems more like security theatre. Someone tell me a realistic situation where there's an organisation that has enough data to need the truck in the first place, someone is willing to commit serious crimes to hijack the truck, someone has the resources to know when and where the truck will be in order to do that, someone has either the resources to undermine the encryption or the opportunity to somehow exploit a presumably relatively short delay in getting the data to its destination, but that someone doesn'
Re: (Score:2)
I can think of state level actors wanting to maintain plausible deniability who might - might - fit that bill. Of course, the attack there is "ensure your agent is the truck driver, and duplicate en route."
Re: (Score:2)
The first customer for the Snowmobile was a GIS company with exabytes of accumulated data spanning years. Their backup tape system failed as they were extracting the data, if it had been irreparable or had corrupted the data during extraction the only copy would have been on the Snowmobile. Destruction of the Snowmobile in that situation would have pretty much destroyed the company. Other than that I believe the primary function of the armed guard is that it's required by contract when transporting gover
Re: (Score:2)
Destruction of the Snowmobile in that situation would have pretty much destroyed the company.
Well, OK, but that company was apparently already being horrendously negligent with its processes if a single point of failure in the backup system could result in losing exabytes of data on which the company depended for its survival. So even if for some reason someone might have wanted to destroy the company and been willing to hit the truck to do it, hopefully that's not exactly a typical situation for a soon-to-be AWS customer.
Other than that I believe the primary function of the armed guard is that it's required by contract when transporting government data so they just made it a part of the standard procedure.
That makes a lot more sense. It might or might not have significant merit as
Re: (Score:2)
You know what's a cheap way to find out that key? An armed thug.
Re: (Score:2)
He'll need to break into Amazon's HQ and hold people hostage to find out who has the key, because nobody on the truck will.
Re: Armed guards? LOL (Score:2)
Just figure out who has the broadest access right in the Amazon network, then add a ransomware agent that puts a new level of encryption on the whole server set. "If you don't send $1 trillion in bitcoins to this address you won't get back the data of your customers".
Re: (Score:2)
The Snowmobile is loaded with RAID arrays, with encryption. I don't know why you would assume they'd ignore that very basic and easy step.
Re: (Score:2)
It makes a lot more sense that they would, and this exposes the only real purpose of the armed guard: as a bit of security theatre.
Re: (Score:2)
Required by government contracts, so they just made the armed guard part of the standard procedure. BTW, they're only involved when the Snowmobile is in transit.
Engineer? No, salescritter (Score:5, Informative)
I really dislike when they call salescritters "engineers". Most of them aren't, most actual data center engineers prefer doing their regular job rather than schmoozing customer's IT managers. At least AWS insists that their salescritters go through the complete training and pass the certification tests, but until they've actually done the job for a while I wouldn't call them an "engineer".
*Full Disclosure*
i used to work at Amazon Web Services, and designed and implemented the security for the initial Snowmobile configs. It was a fun project.
Level five security ain't worthba damn!... (Score:2)
... if the threat sits right inside of its perimeter.
Also, an audit will be cheaper than paying the enemy that acts like your "friend" [twitter.com]. (Monty Python sketch)
Obviously he's talking about management (Score:5, Insightful)
Because I don't know a single sysop that believes a large organization can do something better than they can.
I only mean that in half jest, and it's not meant to sound arrogant ( although I'm sure it is ). Most seasoned sysops have gone through a conversion or two. Maybe they trusted the vendor when they said, "We've got this, you don't have to worry about anything". Then, at "go live", they realized that yes...maybe they should have worried about a few things. Maybe then they realize that the ones who promised the moon were the sales drones ( who really shouldn't be on a customer site without heavy supervision ).
A lot of us have been burned, so when it comes to our data and usability of said data, we're going to pushback to ensure the shit that does hit the fan on "golive" is a smaller, more manageable pile.
Re:Obviously he's talking about management (Score:4, Insightful)
From a management perspective, the problem is they can't tell the difference between a Sysop who can do things, and a Sysop who just talks good. And the ones who talk good are better at selling themselves to management.
Re: (Score:2)
It's actually pretty easy if the employee has been on staff for a reasonable amount of time; what have they accomplished, and have they been right when they've pushed back against something.
Using those two metrics you can get a gauge on the value of any employee. I liked to keep notes on my employees, recording just this data ( because you never remember in the moment when you have some gasbag in front of you mouthing off ).
Re:Obviously he's talking about management (Score:4, Funny)
That's too analytical, you need to rely more on your interpersonal skills. This lack is why you are not a CEO of a big company.
Re: (Score:2)
lol, well you aren't wrong there.
"Level five security"? (Score:5, Insightful)
As soon as someone starts referring to security with numbered levels, and implies that those define the overall security system and controls, they have nearly convinced me that they have gamed those definitions.
Re: (Score:3)
Our security goes to eleven.
Um well :) (Score:2)
Just FYI, security professionals do in fact use numbered levels like OpenSAAM (Software Assurance Maturity Model) and CMMI. Also numbers like 27001:2013 tell you the overall security of a data center.
Those are useful precisely for summarizing "overall security system and controls", something that should be done twice before starting a large security program. For example, a year-long or two-year push to improve security in software development across dozens of teams with hundreds of programmers. Twice becaus
Re:Um well :) (Score:4, Informative)
Just FYI, those numbers do not do that. At all.
Maturity models like you are talking about say what processes an organization has used in the past, and what it has institutionalized to support new efforts. The numerical rating says very little about the quality of any previous technical solution, and absolutely nothing about what will be delivered for the next effort. It only shows what process boxes the organization checks.
In contrast, a security program has to evaluate what a particular system does, what it needs to protect, what the threats are, and then what controls can -- and should -- be applied. Putting security controls into numbered levels, with an upsell strategy, is a one-size-fits-all approach that is almost always going to be tailored to what the vendor sees as its competitive advantages and unique value propositions.
Re: (Score:2)
> The numerical rating says very little about the quality of any previous technical solution, and absolutely nothing about what will be delivered for the next effort.
In my 25 years of experience, performing threat modeling, code review, proper change control, etc absolutely DOES massively improve the security of the code.
Without processes in place, you're simply hoping that a) everyone you've hired knows everything that they might need to know and b) that they never, ever have a bad day - they are never
Re:Um well :) (Score:4, Insightful)
Those aspects are absolutely irrelevant to the way that Amazon was selling the numbers. Remember:
Amazon is never going to do a proper maturity-model assessment of a prospective customer's security capabilities, if that is even the number scheme they are talking about. As others have commented, this is marketing baloney.
Re:Um well :) (Score:4, Interesting)
I'm not sure why you insist that Amazon's team can't help you evaluate your data center security. I can pretty well tell you where your at OVERALL on the 1-4 range in about ten minutes. To solve the problems, to make the security right, we need to take more time getting into specifics. Here's a conversation I had the other day:
Q: Does the tiny data center in that remote location resemble a closet, by chance?
A: Lol no, it's a proper data center.
Q: Cool. Is the door locked right now?
A: Yep. With badge and PIN.
Q: Cool. How many people have access, would my employee badge work?
A: Only me and my deputy have access. Adding a new person requires a CR.
In about 60 seconds I have a pretty good idea of the physical security. I continued with about nine more questions in other areas, and had a pretty darn good idea about the security of the data center in that satellite office.
Again, if I found that the security needed an overhaul that would lead to more questions. It doesn't take long to figure out if the security is shit or not.
Re: (Score:3)
The problem with a lot of formalities like maturity models and ISO standards is that they require you to have a process but they don't necessarily require that process to be any good. Your actual process might require a sensible password hash or it might require SHA1. As long as which one it requires is documented and everyone is following the instructions, the boxes might get ticked for the formalities either way.
That's the difference between level 1 and level 2 (Score:3)
> The problem with a lot of formalities like maturity models and ISO standards is that they require you to have a process but they don't necessarily require that process to be any good. Your actual process might require a sensible password hash or it might require SHA1. As long as which one it requires is documented and everyone is following the instructions, the boxes might get ticked for the formalities either way.
That's basically the difference between level 1 and level 2 and above.
CR1 - you have writ
Re: (Score:2)
If you aren't using SAST tools to check for common things like using the wrong function or cipher, but rather hoping that everyone in the organization knows everything, that's what we call level 1. That's hoping and praying that everyone always catches all errors and understands the problem and the right way to fix it.
There are ALWAYS appropriate tools to check for common problems - some organizations use them as part of their standard process, some don't. When you use them, you then need to staff to eithe
* hash function! (Score:2)
That first sentence was supposed to say "the wrong hash function".
There are tools for every language and library to check for things like using SHA-1. Consistently using those tools to check for things like SHA-1 is the difference between level 1 and level 2.
Now yes, at any level the dev needs to either know what SHA-1 or know who to ask. The difference is that at level 1 you're hoping that all devs know better than to use SHA-1, except in particular rare cases, and they understand what those cases are, an
Re: (Score:2)
Btw:
> a security program has to evaluate what a particular system does, what it needs to protect, what the threats are, and then what controls can -- and should -- be applied
If you're doing all of those things consistently, using proper tools to do so after proper training, we call that CR3. If you do most of those things, except using only generic tools because you've failed to "evaluate what a particular system does", that's CR2. If some employees do some of those things some of the time, that's CR1.
S
Re:Um well :) (Score:4, Insightful)
The number system is useful, but don't mistake it for actual security. For example, you can have enforced code review on every line of code written, but if the reviewers don't know what they are looking for (or don't get paid enough to care) then it's still not going to be secure code.
Re: (Score:2)
This is the "but my craft" vs "but the system" argument. You're arguing for excellent individual craftsmanship. It can produce truly excellent results.
It's also terrible at being deployed at volume and scaled.
He's arguing for building a system to create secure code. It will never be as good on individual case basis as craftsmanship. But it will allow deployment of good enough security at scale.
And if you know anything about security, you should know this. Any security that is more than "good enough" is a ma
Re: (Score:2)
I'm saying that it's fine if you have certifications, it's fine if you have levels, but after all that, you should sit back and ask yourself, "Is my system really secure?"
Re: (Score:2)
Yes, you can look at an individual module written by an individual programmer (or sysadmin or whatever) in a particular week and you can do a security review of that particular code / configuration. You absolutely should do that. You ask questions like "is all input validated" and "does it contain any hard-coded secrets". That's how you figure out the security of those 400 lines of code or config. Let's call that process "security review".
When you have 120 programmers, 30 of which will leave and be replace
Re: (Score:2)
> The number system is useful, but don't mistake it for actual security. For example, you can have enforced code review on every line of code written, but if the reviewers don't know what they are looking for
We call that CR1.
To get to CR2, the reviewers need to have received the appropriate training, be using industry standard tools static analysis tools which will point out common problems, and be using a checklist of application-specific concerns.
At CR3, each time the reviewers find a potential problem
Re: (Score:2)
ok? At the end of the day, you still have to sit down and ask yourself, "is my code review good?" You can't rely on numbers to answer that question.
Re: (Score:2)
Certainly, but no executive will have a clue about that at all and they're the ones who make the decision about whether a program is ready for release or a vendor has acceptable processes. Number systems are all they have to go on.
Re: (Score:2)
But you're not an executive, and you don't have to rely on the same weaknesses they do. You can use your strengths.
Re: (Score:2)
And unfortunately I can't be at ALL of the code reviews.
What I can do is go to the first three each team does, and one a year after that. I need a way to have evidence that they are doing good code review, such as:
I ensure they have training to know how to do so.
I ensure they are WELL aware that my team is available for questions.
I ensure they sign off saying they did the review.
I think you're thinking in terms of what one developer or sysadmin should do. At my last job, I had 120 developers I was respons
Re: (Score:3)
And just for good measure, 27001:2013 is an ISO standard. It also tells you nothing about the security level or controls that a system uses. Like maturity models, it is an entirely process-oriented standard.
I forgot to mention this in my last comment because I almost sprained my eyeballs from rolling them so hard.
Re: (Score:2)
As soon as someone starts referring to security with numbered levels
There's an official classification system used by the US government ( https://reciprocitylabs.com/re... [reciprocitylabs.com] ). It's actually pretty straightforward.
AWS for sure knows about security. They are operating a datacenter for the CIA with "top secret" classification. There are government-certified SCIFs in Amazon buildings, so that engineers with appropriate clearance can support AWS services there.
Re: (Score:3)
Yes, I know about SP.800-53 and the other NIST publications in that family. They do not use numbered levels. Systems that aren't National Security Systems use a three-factor impact rating for each system, rating the consequences of losing confidentiality, integrity and availability of the system -- for example, L-H-M for low impact of losing confidentiality, high impact for loss of integrity, and medium impact for losing availability. National Security Systems are evaluated differently.
But whether an NSS
The truck thing makes no sense (Score:5, Insightful)
they say, yeah, of course I want the giant truck and the guy with a gun to move my data, not some crappy system that I develop on my own.
Nobody says that because that's not how data transfers work.
Transferring data to the cloud isn't an operation of just copying some files via hard drives and *bam* it's done. There is going to be a period of time where you have both systems in place, mirroring data to keep them in sync while you configure and test, then there is a final sync and a cutover. So you have to write that "crappy system" to mirror the data anyway. And you usually do this one system at a time over a period of years. The only time the truck is going to work is for something running on a single server where you can handle significant down time. In that case, you shut the server down, take an image of it, transfer the files, load it onto a VM, and redirect the DNS -- but that is going to take a week whether by truck or airplane or carrier pigeon or internet.
But it sure sounds like a good sales pitch to someone who doesn't know what is involved in doing this.
Re: (Score:3)
Transferring data to the cloud isn't an operation of just copying some files via hard drives and *bam* it's done.
This is ACTUALLY how it was done for at least one $LARGE_CUSTOMER at AWS. They literally closed the shop for a week, put all the data on hard drives, and migrated it to AWS. They were already using VMWare, so they simply booted it on AWS Metal instances.
Re: (Score:2)
Re: (Score:2)
Most data is accessed only sporadically, I'm not sure why you think that it's impossible to move the data that is not in continual use. The first customer for the AWS Snowmobile was a GIS company with several exabytes of data covering a couple of decades, everything that was not in use at that moment was loaded on the Snowmobile, trucked to the AWS DC, ingested, and then the customer changed the pointers from their cold storage tape array to the new location. Over the next several months they moved some o
Are you really comfortable staying where you are? (Score:2)
Re: (Score:2)
All Down To HSMs... (Score:5, Insightful)
1. The security you can apply while your data is moving between the Cloud and your infrastructure.
2. How secure your data can be in the Cloud provider's infrastructure.
Ultimately, both of the above boil down to one thing, the security and integrity of private keys held on the Public Cloud provider's premises.
All of the Public Cloud providers offer HSM (Hardware Security Module) support for larger and enterprise accounts. The HSM's on offer typically include logical partitioning, so that each client organization thinks they are getting either their own dedicated HSM [nope] or a partitioned section of an HSM over which they have total control [uh-uh].
But the problem is that it is the Public Cloud provider that holds the "root" privilege to the HSM and therefore controls access to everything you put in their cloud.
This isn't necessarily a bad thing, of course. Depending on who you are and/or what you want to use the Public Cloud for, this may be perfectly reasonable. If you decide to run all your testing facilities in the Public Cloud [to eliminate peaks and troughs in demand for infrastructure, to say nothing of the endless calls from troublesome developers or DevOps prima-donnas] then the chances are that you're not going to put too much of significant value in the Public Cloud [unless your program logic is particularly sensitive or contains significant corporate IP. If you're using it for elastic compute capabilities - even for Production data, you might be OK, depending on how you move that data between your infrastructure and the cloud and how much of that data is "exposed".
But if you have confidential data, or data including Personal Information for your clients [for example data expressly covered by the EU GDPR] and you put that in the Public Cloud, well, good luck to you.
Remember, this is basic chain-of-trust stuff... and if the root of that chain is an HSM owned by your provider, then you can never claim that your use of Public Cloud is secure. Anyone who tells you otherwise is a liar, a snake-oil salesman, or works for the Cloud provider. Maybe all three.
Re: (Score:3)
But the problem is that it is the Public Cloud provider that holds the "root" privilege to the HSM and therefore controls access to everything you put in their cloud.
AWS used to offer support for customer-provided HSMs (you physically ship it to them and they connect it to a special server). But it gained almost no attention.
And AWS quite explicitly does NOT have root access to the HSM hardware, they can't access your key material. The hardware that is used is audited and certified to comply with FIPS regulations.
If you mistrust the certification, then you can provide your own custom key management and use BYOK (bring your own key) support to ship wrapped keys from
Re: (Score:2)
Gotta love the folks who make sweeping statements about something they know nothing about.
Re: Neal Stephenson, are you listening? (Score:2)
Let's settle on "One-eyed Neil Stephenson knock-off for blind Neil Stephenson knock-off fans". :)
"Fall" was rather disappointing (Score:2)
Premise: Trolls are losers.
Conclusion: The only reason to play with a troll is if it's a lose-lose game and you have a guaranteed lose-less strategy.
For example, consider this no-reason-for-existing AC FP thread. The more briefly you consider it, the better.
Re: (Score:2)
It's news because it was an "anonymous engineer" who is pretending he is whistleblowing, and is totally not a salesperson with it as part of his job description, providing this information to the press. Just like how there's going to be an "anonymous sexual partner" telling the "totally unauthorized" story about how my penis is very large and I am the best lover in the history of the world and here's my contact information.
Re: (Score:2)
Nothing like talking out of your ass about something you know nothing about.
Re: nothing says security (Score:2)
And then there's a war between India and China cutting out everyone with Admin rights.
Re: (Score:2)
Security guard is a shitty, boring, low paying job. Armed security guards generally make about half again what the unarmed ones for doing the same shitty boring job.