DEVOPS: What is a security posture, and what can you do to improve it?

A security posture is a term used to describe how relaxed or strict your security is in your organisation, in a project, or for a service.

Note: I use some links for examples below, and the cloud provider for all cloud examples is AWS, however the technologies discussed aren't exclusive to AWS in any way.

When reviewing a security posture these key sections should be assessed:

• Exploitation
• Exposure
• Recovery

Exploitation

Starting points for exploitation management

• Have known risks been remedied, such as security patch compliance reporting and operating system hardening?
• Are the very easy to use security tools available at your cloud provider being used, such as Amazon Inspector, and Guard Duty
• Has the perimeter (where information enters or exits the network) had its firewall rules to restrict communication between services to comply with known ports and routes (known as egress traffic filtering)?
• Is there IDS (intrusion detection system) in place and/or a WAF (web application firewall) to scan for and prevent anomalous traffic from reaching your system?
• How can the application be hardened according to OWASP Application Security Risk Assessment?
• Use CIS benchmark alerts for your cloud platform to watch for exploits.

Exposure

Starting points for exposure management

• Do the staff have training on what security awareness is? While this is usually done for compliance with government or corporate standards, this training is easy, memorable, and worthwhile for companies of all sizes. Document rules and expectations for engineers - A single front page and often seen list on an internal wiki can go a long way: You must use two factor authentication, Use role based access and never access keys/secrets, no shared SSH keys... etc.
• Are there logs in place that allow for auditing and identifying users and their activity?
• Are your engineers and application privileges complying with the least privilege policy?
• Remove the use of all root accounts, and protect root accounts with MFA (multi factor authentication). TIP: keep recovery codes with business continuity documentation printed out and ideally kept with counsel. You don't want to have someone senior pass away with their laptop encrypted.
• Is your data encrypted at rest and in transit? This is very easy to learn how to do, and in most cases requires an extra tick in a box when creating resources.
• Have you passed the Cloud Security Assessment Self Test?

Recovery

Starting points for recovery

• Do you have documented and tested backup and restore steps for your system? This includes your application state management, databases, data file storage, and configuration management.
• Do you have business continuity plans in place - i.e. what you are going to do in the event of a breach, exposure, or loss?
• Are there measures in place for notifying the correct staff, C-Level execs, Shareholders, or Authorities if a security breach happens or data is lost or stolen?

Security in the cloud is broad, very detailed and often specific to your circumstance. Having a third party assessment for your system, application, service, or users is an easy and recommended step to take.

What else are you doing to improve your security posture?

Which third party DevSecOp companies do you recommend and where they are based?

Comments or corrections welcomed!