Pulling security to the left: How to think about security before writing code – TechRepublic

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 everyones responsibility.

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 Amazons 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.

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.

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.

Once you know what your security controls are and where they should be applied, youll not want to leave anything to human error. Thats 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 doesnt adhere to the security rules youve defined. No matter how trivial the configuration may seem, you dont 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.

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.

When properly executed, the SbD approach provides a number of tangible benefits.

Additionally, whether on-premises or in the cloud, make sure your security policies address the following vectors:

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 weve compiled the 2022 top list of threats.

While its 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), its 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. Youll find these tools mostly targeted at a particular technology, and the attacks unique to it.

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 dont inadvertently compromise the overall security of the system. Make sure as an organization you are following best security practices around account management:

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. Its 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.

Its 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. Thats why its paramount that organizations lean into securing applications from the onset.

Reactive security measures will not succeed in todays 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.

Read more:

Pulling security to the left: How to think about security before writing code - TechRepublic