After the last blog post about SSDF, I decided to pick something much easier to write about, and it happens to be at the top of the list. We’ll cover PO.1 this time, it’s the very first control in the SSDF. The PO stands for Prepare the Organization. The description is
Define Security Requirements for Software Development (PO.1): Ensure that security requirements for software development are known at all times so that they can be taken into account throughout the SDLC and duplication of effort can be minimized because the requirements information can be collected once and shared. This includes requirements from internal sources (e.g., the organization’s policies, business objectives, and risk management strategy) and external sources (e.g., applicable laws and regulations).
How hard can it be to prepare the organization? Just tell them we’re doing it and it’s a job well done!
This is actually one of the most important steps, and one of the hardest steps when creating a secure development program. When we create a secure development program we really only get one chance with developers. What I mean by that is if we try to keep changing what we're asking developers to do we create an environment that lacks trust, empathy, and cooperation. This is why the preparation stage is such an important step when trying to deploy the SSDF in your organization.
We all work for a company whose primary mission isn't to write secure software, the actual mission is to provide a product or service to our customers. Writing security software is one of the tools that can help with the primary mission. Sometimes as security professionals we forget this very important point. Security isn't the purpose, security is part of what we do or at least it should be part of what we do. It's important that we integrate into the existing process and procedures that our organization has. One of the reference documents for PO.1 is NIST 800-161, or Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. It’s worth reading the first few sections of NIST 800-161 not for the security advice, but the organizational aspect. It stresses the importance of cooperation and getting the company to buy into a supply chain risk management program. We could say the days of security-making mandates are over, but they probably never really existed.
The steps to prepare the organization
The PO step of the SSDF is broken into three pieces. The first two sections explain how to document the process we're going to have to create and implement. The third section revolves around communicating these documented processes. This seems obvious, but the reality is it's something that doesn't happen on a regular basis. It's really easy for a security team to create a process, but never tell anyone about it. Telling people about the process is harder than creating the process in many instances. It’s much harder to bring that process and policy to another group and collect their feedback on it and make sure they buy into it.
PO.1.1: Infrastructure security requirements
The first section is about documenting the internal infrastructure and process. There's also a mention in the first control to maintain this documentation over time. It’s possible your organization already has these documents in place, if so, good job! If not, there’s no better time to start than now. SANS has a nice library of existing security policy documents that can help get things moving. The intention of these isn’t to take them as is and declare it your new security policy. You have to use existing documents as a guide and make sure you have agreement and understanding from the business. Security can’t show up with a canned document they didn’t write and declare it the new policy. That won’t work.
PO.1.2: Software security requirements
The second section revolves around how we're going to actually secure our software and services. It’s important to note this control isn’t about the actual process of securing the software, but documenting what that process will look like. One of the difficulties of securing the software you build is there are no two organizations that are the same. Documenting how we're going to build secure software or how we're going to secure our environment is a lot of work. OWASP has a nice toolbox they call SAMM, or Software Assurance Maturity Model, that can help with this stage.
There’s no shortcut to building a secure development program. It’s a lot of hard work and there will be plenty of trial and error. The most important aspect will be getting cooperation and buy in from all the stakeholders. Security can’t do this alone.
PO.1.3: Communicate the requirements
The third section talks about communicating these requirements to the organization. How hard can communication be? A security team can create documentation and policy that is fantastic, but then they put it somewhere that the rest of the company might not know exists or in some cases, the rest of the company might not even be able to access.
This is obviously a problem because it has to be something that everyone in the organization is aware of and they know where to find it they know how to get help and they know what it is so it can't be stressed how truly important this stage is. If you tell your developers that they have to follow your policy and it's not well written or they can't find it or they don't understand why something is happening, those are developers that aren't going to engage and they aren't going to want to work with you
Next steps
If you’re on a journey to implement SSDF, or you’re just someone looking to start formalizing your secure development program, these are some steps you can start taking today. This blog series uses SSDF as our secure development standard. You can start by reading the content NIST has published on their site Secure Software Development Framework. You can follow up on the SSDF content with a tour of the SANS policy templates. Most of these templates shouldn’t be used without customization. Every company and every development team will have unique processes and needs. The CSA has a nice document called CAIQ, or Consensus Assessment Initiative Questionnaire that can help create some focus on what you need. Combining this with a SAMM assessment would be a great place to start.
And lastly, whatever standard you choose, and whatever internal process you create, it’s important to keep in mind this is a fluid and ever-changing space. You will have to revisit decisions and assumptions on a regular basis. The SSDF standard will change, your business will change, everything will change. It’s the old joke that the only constant is change.
Want to better understand how Anchore can help? Schedule a demo here.
Josh Bressers
Josh Bressers is vice president of security at Anchore where he guides security feature development for the company’s commercial and open source solutions. He serves on the Open Source Security Foundation technical advisory council and is a co-founder of the Global Security Database project, which is a Cloud Security Alliance working group that is defining the future of security vulnerability identifiers.
