Pulling security to the left: How to think about security before writing code
Involving everyone in security, and pushing crucial 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 how we run our businesses to how 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 digital applications and ecosystems is everyone’s responsibility.
A new approach: Security 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 publication of an Amazon White Paper in 2015, SbD is still Amazon’s recommended framework today for systematically approaching security from the onset. SbD is a security assurance approach that formalizes security design, automates security controls and streamlines auditing. The framework breaks securing an application down into four steps.
Know your requirements
Outline your policies and document the controls. Decide what security rules you want to enforce. Know which security controls you inherit from any of the external service providers in your ecosystem and which you own yourself.
Build 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 note them at each component.
SEE: Hiring kit: Data scientist (TechRepublic Premium)
For example, if your application requires encryption of data at rest, mark any data stores with an “encrypted = true” tag. If you are required to log all authentication activity then tag your authentication components with “log = true”. These tags will keep security top of mind and later inform you of what to templatize.
Enforce through policies, automation and templates
Once you know what your security controls are and where they should be applied, you’ll not want to leave anything to human error. That’s where your templates come in. By automating infrastructure as code, you can rest easy knowing the system itself prevents anyone from creating an environment that doesn’t adhere to the security rules you’ve defined. No matter how trivial the configuration may seem, you don’t want admins configuring machines by hand, in the cloud or on-premises. Writing scripts to make these changes will pay for themselves a thousand times over.
Perform regular validation activities
The last step in the security by design framework is to define, schedule and do regular validations of your security controls. This too can be automated in most cases, not just periodically but continuously. The key thing to remember is that you want a system that is always compliant, and as a result the system is always audit ready.
What’s the return on investment of SbD?
When properly executed, the SbD approach provides a number of tangible benefits.
- Forcing functions that cannot be overridden by users who aren’t authorized
- Reliable operation of controls
- Continuous and real-time auditing
- Technical scripting of your governance policy
Additionally, whether on-premises or in the cloud, make sure your security policies address the following vectors:
- Network security
- Inventory and configuration control
- Data encryption
- Access control
- Monitoring and logging
Maintain awareness of top threats
When it comes to the actual application development, be aware of the OWASP Top 10. This is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications. It changes over time, but below we’ve compiled the 2022 top list of threats.
- Broken access control
- Cryptographic failures
- Injection
- Insecure design
- Security misconfiguration
- Vulnerable and outdated components
- Identifications and authentication failures
- Software and data integrity failures
- Security logging and monitoring failures
- Server-side request forgery
While it’s important for your developers to understand these threats (step one of the SbD process) so that they can identify proper controls and implement accordingly (steps two and three), it’s equally important that the validation activities (step four) are applied during and after the development process. There are a number of commercial and open source tools that can assist with this validation.
The OWASP project keeps an updated list of these tools, and even maintains a few of these open source projects directly. You’ll find these tools mostly targeted at a particular technology, and the attacks unique to it.
Account-level best practices
No organization can be truly secure without mitigating the largest risk to security: The users. This is where account best practices come in. By enforcing account best practices, organizations can make sure their users don’t inadvertently compromise the overall security of the system. Make sure as an organization you are following best security practices around account management:
- Enforce strong passwords on all resources
- Use group email alias at account level
- Enable MFA
- Never use root for day-to-day access
- Delete account-level access keys
- Enable logging
Remember compliance and regulatory requirements
In some industries or geographies, you will need to conform to additional security controls. Common ones include PCI for payments and HIPAA for medical records. It’s crucial 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 that specializes in the particular controls needed, as violations often carry stiff fines.
It’s important to remember that while organizations are the targets of cyber attacks, 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 paramount that organizations lean into securing applications from the onset.
Reactive security measures will not succeed in today’s fast paced digital environment. Savvy CIOs are taking a proactive approach, pulling security conversations to the left, involving the entire business and embedding best practices in every step of the software development lifecycle.
