Rob is a manager for a newly developed product which is getting customer interest and starting to sell nicely. The development team is gearing up for the next program increment planning.
One morning, Rob gets a request from the delivery team asking for a “security report” of the product urgently, without that the customer will not allow any production deployment unless the security aspects are “cleared” by their security team. Rob now runs to his team to generate some kind of security evidence that summarises what security measures have been taken to protect the product. Since it has never been done before, Rob is worried that that additional work to create this security report, hopefully doesn’t affect the schedule for the next release.
This sounds very familiar, right?
With a large number of security incidents that have been publicised lately, it is expected of anyone to be paranoid and ask for assurances when it comes to software security. And you should ask such assurances from your software vendor too! (CIO has this good list of security questions to ask your software vendor). In the above case, if the team would have been proactively working on the security aspects of the product, they would have likely had “something” to quickly create a report and give it to the delivery team in distress.
Here are some ingredients for the the security cake. This list by no means will make you compliant with well known security standards (e.g. ISO 27001) but rather is intended to “get started” when it comes to product security. Each of these ingredients are an area on their own (this blog post is not enough to cover each in detail). However, in my opinion, the below points set a good foundation to build upon.
A product security policy for the organisation
A security policy defines what are the security specific expectations of the organisation. A policy is (in general) a set of rules and requirements but may also contain necessary guidance. It typically boils down to describing the security requirements for protecting the confidentiality, integrity and availability of the organisation’s (and it’s customers’) information as well as computer systems. A security policy also describes the necessity to comply with legal requirements (e.g. laws, regulations and contracts) such as GDPR as well as standards such as PCI-DSS, if required.
There need not be a separate product security policy, however, and organisations may chose to have a single security policy. It depends on the organisation on how to organise their policies.
A security policy is generally organisation-wide. If your organisation does not have one, then pressure the top management to chalk one out. You can talk to a security consulting company or perhaps write your own. To get started, SANS offers great resources in the form of policy templates.
A security mindset
It is often said that the “human” is the weakest link in the security chain. The human could be a software developer, administrator or the user of your product. It is important to educate all the stakeholders on the what security means in their context. A security mindset is a way of thinking where the question “could someone subvert security or privacy by doing something on what I am working on?” is always on the mind. (Here’s a nice explanation from Bruce Schneier on the security mindset)
Merely educating the stakeholders on security likely won’t help. Software developers know that they are expected to write secure code, but they lack resources and help needed to do so. Admins and users do not know how to configure and securely use the software because they simply haven’t been instructed clearly. Hence it is important to convey the point of security clearly to the stakeholders with valid reasoning.
For example, Do not “order” your coders to write secure code, rather provide them convincing reasons (e.g. protecting user data is important because a breach and leakage of that data will cause distress to both the user and loss of reputation for the company). More importantly, provide them resources such as automated code scans (in the IDE itself), secure coding training, as well as training on how to develop the security mindset.
A security engineering process
A security engineering process aims to practically achieve the goals of the security policy. There is a huge variety of security engineering processes that are out there to chose from. Here’s to name a few common ones:
Essentially, a security engineering process should be able to touch the following aspects:
- Finding security flaws (Threat and risk assessment)
- Fixing security flaws at the design and development phase (Security architecture, secure coding, hardening, etc.)
- Checking if security flaws are fixed (Security Testing)
- Ensuring vulnerabilities are proactively fixed on time
If you are doing agile software development, ensure that the security engineering process is followed in each sprint (or program increment, depending on how you want to organise things).
A security champ (or lead)
Although not 100% required, but it makes a difference to appoint someone to guide the security related activities concerning the product. This does not necessarily mean hiring a new security expert. Anyone can take up the role to ensure the following:
- Ensure the security engineering process is followed diligently
- Promote secure development practices and enable knowledge sharing
- Be a single point of contact for vulnerability reporting
- Be a single point of contact for answering security related requests/proposals.
- Ensure the security state of the software is incrementally improved
For example a security lead can be a scrum master, a product owner, or even a product manager. That is, someone who closely works with the development team.
A word of caution though — You should appoint someone who is a good team player and works closely with development teams. Otherwise, you don’t want to fall prey to the game of egos where everyone starts hating the security expert or the security expert only functions to broadcast his noble knowledge and say “I told you so” when crisis hits. It is important that security is not imposed, but rather engineered in the product.
An evidence of security assurance
Security assurance is like quality assurance. An evidence of security assurance affirms that the security engineering process has been applied. It also helps keep track of the shortfall and helps measure progress in each revision.
An evidence of security assurance will help answer the security related questions from customers. Furthermore, it instills confidence and restores customers’ faith in your software development capabilities. Lastly an evidence of security assurance makes your product competitive in the market against similar products who fail to furnish one.
The following items can be considered as an evidence of security assurance:
- Report of threat assessment and mitigation applied
- Report of security testing
- Report of vulnerabilities fixed
There are lot of ways to approach product security. I do not claim that the above is the best approach. However, I think the above five ingredients can get a product team or a small organisation get started with approaching security.
As I said, security is something that should not be “applied” to a product but rather “engineered” within. This means considering security aspects during design, development, testing, and deployment phases. And that’s what a high level security engineering process it and it’s not very difficult. Once you start, the process can be tweaked to suit your needs and perhaps evolved further to achieve compliance towards a well known standard such as ISO 27001, CMMI Security or others.