10 things security teams should focus on, according to AWS' CISO

Amazon Web Services (AWS) chief information security officer and president of security engineering Steven Schmidt has detailed 10 things he thinks should be of the highest value to every security group.

1. Accurate account info

Schmidt said AWS constantly notifies customers when it notices security problems, such as if they're under attack by somebody on the outside or if there's a misconfiguration somewhere.

In order to do that, Schmidt said AWS has to be able to get a hold of them.

"Now a customer who has an enterprise contract with us has very good support contacts, they've got a defined person or persons, their operation centres, phone numbers, email addresses, etc, but many customers may not look at their email all the time, the email address they use to set up the account may not be monitored by somebody," he said.

"It sounds trivial, but it's actually critically important for our ability to tell them, 'Hey, something's going on, you need to pay attention to and wake up'".

2. Use MFA

Using multi-factor authentication (MFA) is critical to the integrity of accounts, Schmidt said.

"Whether it's your social media account, or AWS account, there's really no excuse right now for not using multi-factor authentication, it is easy, it's painless, in many cases, you can get it right as a text message on your device," he said.

"There are of course gradients of security with different kinds of multi-factor text messages, some not awesome, but you can use real, hard multi-factor if you want, including tokens, like the FIDO key that I have sticking out of my laptop right now."

He emphasised MFA prevents whole classes of adversarial attacks.

3. No hard-coding secrets

"Customers should not ever code usernames, passwords, or keys into their software," he said.

"How many times have we seen stories about people whose access keys were posted to GitHub, picked up by an adversary and then that adversary either used their resources to mine Bitcoin -- which is the biggest thing -- or stole data of theirs because their keys were in GitHub or some other location."

Schmidt said there are a trove of services that help organisations build software securely without putting keys into it.

4. Limit security groups

"This is one of those things that's really boring," he said. "In many ways, it's about firewall rules."

Pointing to AWS EC2, Schmidt said every EC2 virtual machine comes with a firewall wrapped around it, which is closed by default.

"Sometimes customers developers get lazy, and they open those firewalls up more broadly than they should. And as part of the normal kind of operations cycle of business, you should be constantly checking to see 'is this required to be like this?' or can it be scoped downward to make my resources more secure?"

5. Intentional data policies

Schmidt stressed the word intentional.

"You've probably heard about a lot of data storage policies … where they say you shouldn't store PII unsafely, or you need to be secure when you store PII, or you should never store PII on your laptop -- all of those are negative statements," he said.

"They're telling people not to do something.

"Developers are not inherently evil, they don't want to do something wrong, they want to do the right thing."

However, Schmidt said the industry isn't telling them how to do the right thing.

Intentional data policy, he explained, would instead be saying: "If you want to store PII, put it here using this encryption, this kind of access control, and this kind of monitoring".

Schmidt said this had to be flipped at Amazon before he joined as the person running security for AWS.

"Our security organisation was like many, many company's security organisations; it was a lot of 'don't do this' kind of rules," he said. "We realised when we told people how to do things safely and securely we got a whole different result. It was miraculous in the change that had in the organisation."

6. Centralise logs

"Everybody knows that logs are super, super important," he said.

"The sort of the joke here is that nobody has yet figured out a way to recreate logs that were sent to the garbage can. If we can do that, that's an awesome service, we should probably roll it out."

Schmidt said in reality, without a way to keep logs, organisations won't be able to understand what happened after an event occurred.

"There is no excuse for not keeping logs now," he said. "Because you simply cannot understand what happened if you don't have logs."

7. Validate IAM roles

"Identity and access management is a way of understanding which person is directing which action on our infrastructure," he explained.

Schmidt said that if a developer had keys to a certain set of data because they were building something, once that software is shipped, the question needs to be asked if they still need those keys or if access should instead be revoked.

"A lot of people slowly keep increasing access to information without consciously saying, 'is there a point where we should be shrinking that back down again'," he continued.

"I spent a lot of time talking about getting humans away from data, because humans make mistakes, they have bad days, they get their laptop stolen, they do stupid things because they're mad -- get people away from data."

8. Take action on GuardDuty findings

Although AWS GuardDuty is a service offered by the cloud giant, Schmidt said people need to pay attention to the alarms that they get.

"The best way to pay attention to alarms that you get is automation," he said.

"It is one of those areas that is eminently amenable to automation. Alarm goes off, there is a set of things which must have occurred next, write the software, use the tools, use a partner's services … then take an action on each one of those alarms."

9. Rotate keys

"Security credentials are awesome, encrypting stuff is great," Schmidt said.

However, if the same key is used for years, Schmidt said the exposure window to a problem is very broad.

"If you talk to people who are deep into cryptography, they'll tell you regular rotation of keys means you limit the blast radius for an individual key leak dramatically," he said.

10. Being involved in the development cycle

Schmidt wants to see more security folk involved in the development cycle.

"Anybody who bolts security on at the end of a software development cycle is asking for a mess, because they're either going to have to go back and redo a bunch of work when they discover a problem, or they're going have to say, 'I'm sorry, we've got to ship this because it's already done', and they're going to have security vulnerabilities down the road," he said.

"If you can go into the development cycle along the way, checkpointing things to make sure that there's nothing you need to fix, adjusting in the short term is so much more effective."

Asha Barbaschow travelled to re:Invent as a guest of AWS.

SEE ALSO

from Latest Topic for ZDNet in... https://ift.tt/2REHgbO