Pulling security to the left: how to think about security before writing code
Getting everyone involved in security and pushing critical conversations to the left will not only better protect your organization, but also make the process of writing secure code easier.
Technology has transformed everything from the way we run our businesses to the way we live our lives. But with that convenience comes new threats. High-profile security breaches at companies like Target, Facebook and Equifax are reminders that no one is immune. As technology leaders, we have a responsibility to create a culture where securing applications and digital ecosystems is everyone’s responsibility.
A new approach: safety by design
One approach to writing, building, and deploying secure applications is known as security by design, or SbD. Taking the cloud by storm after the release of an Amazon white paper in 2015, SbD is still Amazon’s recommended framework today for systematically addressing security from the start. SbD is a security assurance approach that formalizes security design, automates security controls, and streamlines auditing. The framework breaks down securing an application into four steps.
Know your requirements
Describe your policies and document the controls. Decide on the security rules you want to apply. Know which security controls you inherit from one of your ecosystem’s external service providers and which you own yourself.
Create a secure environment to meet your documented requirements
As you begin to define the infrastructure that will support your application, refer to your security requirements as configuration variables and write them down at each component level.
SEE: Recruitment kit: Data scientist (TechRepublic Premium)
For example, if your application requires encryption of data at rest, mark all data stores with an “encrypted=true” tag. If you need to log all authentication activity, tag your authentication components with “log=true”. These tags will keep safety in mind and inform you later what to model.
Enforce through policies, automation, and templates
Once you know what your security controls are and where they should be applied, you won’t want to leave anything to human error. This is where your models come in. By automating infrastructure as code, you can rest easy knowing that the system itself prevents anyone from creating an environment that violates the security rules you have. defined. As trivial as setup may seem, you don’t want admins configuring machines by hand, in the cloud, or on-premises. Writing scripts to make these changes will be a thousand times more profitable.
Perform regular validation activities
The final step in the security-by-design framework is to define, plan, and perform regular validations of your security controls. This too can be automated in most cases, not only periodically but continuously. The key thing to remember is that you want a system that is always compliant, and therefore the system is always audit ready.
What is SbD’s return on investment?
When executed correctly, the SbD approach offers a number of tangible benefits.
- Force functions that cannot be overridden by unauthorized users
- Reliable control operation
- Continuous and real-time auditing
- Technical scripting of your governance policy
Additionally, whether on-premises or in the cloud, ensure that your security policies address the following vectors:
- internet security
- Inventory and configuration control
- Data encryption
- Access control
- Monitoring and logging
Maintain awareness of key threats
When it comes to actual app development, be aware of the OWASP Top 10. This is a standard web application security and developer awareness document. It represents a broad consensus on the most critical security risks for web applications. This changes over time, but below we have compiled the list of top threats of 2022.
- broken access control
- Cryptographic failures
- Insecure design
- Misconfiguration of security
- Vulnerable and outdated components
- Identifications and authentication failures
- Software and data integrity failures
- Security logging and monitoring failures
- Server-side request forgery
While it is important for your developers to understand these threats (Step 1 of the SbD process) so that they can identify appropriate controls and implement them accordingly (Steps 2 and 3), it is equally important that validation (step 4) are applied during and after the development process. There are a number of commercial and open source tools that can help with this validation.
The OWASP project maintains an up-to-date list of these tools, and even directly manages a few of these open source projects. You will find these tools mainly targeted at a particular technology and the attacks specific to it.
Account-Level Best Practices
No organization can be truly secure without mitigating the greatest security risk: users. This is where account best practices come in. By applying account best practices, organizations can ensure that their users do not inadvertently compromise overall system security. Make sure as an organization that you follow security best practices for account management:
- Enforce strong passwords on all resources
- Use group email alias at account level
- Enable MFA
- Never use root for daily access
- Delete account-level access keys
- Enable logging
Don’t forget compliance and regulatory requirements
In certain industries or geographies, you will be required to comply with additional security checks. Common ones include PCI for payments and HIPAA for medical records. It is crucial that you do your homework, and if you find yourself subject to any of these additional security requirements, it may be worth contacting a security consultant who specializes in the particular controls needed, as breaches often result in heavy fines.
It is important to remember that while organizations are the targets of cyberattacks, the victims are individuals: they are your customers; they are your employees; they are real people who have put their trust in you and your technology. That’s why it’s important for companies to consider securing applications from the start.
Reactive security measures will not succeed in today’s fast-paced digital environment. Savvy CIOs take a proactive approach, pulling security conversations to the left, involving the entire enterprise, and integrating best practices at every stage of the software development lifecycle.