diff --git a/1-secure-development-is-everyones-concern.md b/1-secure-development-is-everyones-concern.md index 9a90189..fa73734 100644 --- a/1-secure-development-is-everyones-concern.md +++ b/1-secure-development-is-everyones-concern.md @@ -14,7 +14,7 @@ Every team needs security expertise, but not everyone on the team needs to be a During design and delivery, continuously ask questions, discuss and identify potential security issues and work together to deliver solutions. Embed this process within your 'normal' approach to product delivery. -Security mistakes, and the associated security 'debt' which these entail, can be avoided if security is made part of everyday practice by your whole team. If this doesn't happen and security is considered as a 'bolt-on' once development is complete, then vulnerabilities may be missed and customer expectations may not be met. Both of these can lead to time-consuming and expensive re-working of code. +Security mistakes, and the associated security 'debt' which these entail, can be avoided if security is made part of everyday practice by your whole team. If this doesn't happen and security is considered as a 'bolt-on' once development is complete, vulnerabilities may be missed and customer expectations may not be met. Both of these can lead to time-consuming and expensive re-working of code. Unfortunately, the security process is too often about achieving standards compliance and ticking boxes rather than delivering practical and pragmatic security outcomes. Developing a culture of encouraging people to ask questions and discuss potential security issues can help to overcome this. @@ -35,7 +35,7 @@ Software development is a community activity. A healthy community should include ## Actions -* **Define and articulate the requirements for security at the start and during product delivery** +* **Define and articulate the requirements for security at the start of and during product delivery** Without this, security practices are unlikely to take hold and be given the priority they need. 'Top-down' support should be provided. * **Security is an essential skill for every member of the delivery team** @@ -65,11 +65,11 @@ Software development is a community activity. A healthy community should include ## Self assessment -These examples are intended to help you assess your own practices, and those of your suppliers. The list below is not exhaustive. +These examples are intended to help you assess your own practices, and those of your suppliers. The list below is not exhaustive and is not intended to be used as a checkbox exercise. | BAD | GOOD | |-----|------| -| Security specialists do not consider the legitimate needs of the business alongside security. | Leaderships views spotting and fixing security issues as a positive. | +| Security specialists do not consider the legitimate needs of the business alongside security. | Leadership views spotting and fixing security issues as a positive. | | Security requirements are often postponed to meet release deadlines, regardless of their impact. | Product engineering staff review security incidents and seek to learn from them. | | Developers hide their mistakes.| Security implications are considered at every sprint planning meeting. | | Developers do not take ownership of their code and seek to make security another person's responsibility. | There's top-down support for security within your organisation. | diff --git a/2-keep-your-security-knowledge-sharp.md b/2-keep-your-security-knowledge-sharp.md index 4a240a8..821b2d2 100644 --- a/2-keep-your-security-knowledge-sharp.md +++ b/2-keep-your-security-knowledge-sharp.md @@ -17,7 +17,7 @@ Teams armed with up to date information are much more likely to implement approp If they do not already have this knowledge, resources should be provided so that it can be gained. Examples may include standard injection techniques and handling [untrusted input](https://www.owasp.org/index.php/Injection_Theory). * **Use your developer recruitment process to screen for basic security awareness** - Qualifications aren't the only way to establish this. Real world practical application is more important. If this isn't possible, allocate extra resources for security learning and development. + Qualifications aren't the only way to establish this. In fact, real world practical application is more important. If this isn't possible, allocate extra resources for security learning and development. * **Make time and resources available for ongoing learning** Invest in training to develop security knowledge and skills. @@ -28,7 +28,7 @@ Teams armed with up to date information are much more likely to implement approp * **Make developers accountable for the security of their code** Most developers already take pride in their work - [security is everyone's concern](2-keep-your-security-knowledge-sharp.md). -* **Be aware and consider when there is a particular need to write code defensively** +* **Be aware when there is a particular need to write code defensively** Take extra time and care when implementing security critical components, writing your code defensively. For example, when validating input which may be attacker-controlled. * **Get your security specialists to outline **for developers** which **components are** security-critical (this should not be 'everything')** @@ -68,3 +68,4 @@ These examples are intended to help you assess your own practices, and those of * [Secure design principles](https://www.ncsc.gov.uk/guidance/security-design-principles-digital-services-main) * [http://www.riscs.org.uk/wp-content/uploads/2015/12/Awareness-is-Only-the-First-Step.pdf](http://www.riscs.org.uk/wp-content/uploads/2015/12/Awareness-is-Only-the-First-Step.pdf) +* [https://www.ncsc.gov.uk/cisp](https://www.ncsc.gov.uk/cisp) diff --git a/3-produce-clean-and-maintainable-code.md b/3-produce-clean-and-maintainable-code.md index ef10972..63c9281 100644 --- a/3-produce-clean-and-maintainable-code.md +++ b/3-produce-clean-and-maintainable-code.md @@ -31,7 +31,7 @@ Writing defensive code will be easier to achieve, security mistakes easier to sp Having two or more people review code will increase your confidence in the quality and security of your product before release. This process should be enforced within your deployment pipeline to help reduce the likelihood of damaging code changes being pushed to your production environment. -Any issues identified should be followed through with a fix. Remember, individuals can also peer review their own code, which can often save time before another person looks over it. +Any issues identified should be followed through with a fix. Remember, individuals can also review their own code, which can often save time before another person looks over it. When reviewing code, you should consider: @@ -51,7 +51,8 @@ The code that you write often only makes up a small fraction of the total code b There is no easy way to mitigate the risks of third party code, but asking these questions may help: * If there is a security vulnerability in the third party components of your code, what security impact may this have on your system? -* Is the dependency actively developed and maintained? If a vulnerability is found, who will fix it? +* Is the dependency actively developed and maintained? +* If a vulnerability is found in one of your dependencies, would you know? Who would fix it? * Are you using any old versions of third party code known to contain security vulnerabilities? * Do you know anything about the author and maintainer of the dependency? How do they view and approach security? * Does the dependency have any history of security vulnerabilities? What's important here is not necessarily that issues are discovered, but how they are handled. @@ -76,7 +77,7 @@ There is no easy way to mitigate the risks of third party code, but asking these Understanding code becomes more difficult when different coding styles used by different developers mix and intertwine. * **Clearly outline code block responsibilities** - Security issues can arise when one code component inaccurately assumes another has taken responsibility for an action. For example, when validating potentially malicious input at the border of your application. One way to achieve this is to have a comment block at the top of every method or function. + Security issues can arise when one code component incorrectly assumes another has taken responsibility for an action. For example, when validating potentially malicious input at the border of your application. One way to achieve this is to have a comment block at the top of every method or function. * **Separate secret credentials** Keep secrets such as passwords and private keys logically isolated from the core code base. This will help prevent them being checked in to public code repositories. Hard coding credentials in source code is bad practice. @@ -91,7 +92,7 @@ There is no easy way to mitigate the risks of third party code, but asking these Encourage a culture that does not accept complicated, confusing or insecure coding practices. Peer review helps prevent such issues being incorporated into your code base. Feedback helps support education within your team. Using pull requests and comments is one way to achieve this. * **Team communications** - When multiple team members are working on the same code base, there should be strong and regular communication channels between them. The aim here is to avoid the following scenario: 'I thought you were securing that component!'. Keeping teams physical close to one-another, or providing real-time chat channels are two ways to achieve this. + When multiple team members are working on the same code base, there should be strong and regular communication channels between them. The aim here is to avoid the following scenario: 'I thought you were securing that component!'. Keeping teams physically close to one-another, or providing real-time chat channels are two ways to achieve this. * **Document and comment clearly and consistently** Clear and concise documentation should support your product. This may be as a result of self-documenting code, code comments, or supportive material. Documentation should be kept up to date, as a system evolves. Old and out-of-date documentation is difficult to trust and could be damaging for security if it's interpreted incorrectly. @@ -100,7 +101,7 @@ There is no easy way to mitigate the risks of third party code, but asking these Developers and other team members may come and go over the life span of a product. To ensure adequate knowledge of the product is maintained, provide good support and documentation to new team members. After all, who will fix security vulnerabilities left behind by previous developers? * **Check return values and handle errors appropriately** - Checking for errors at the point of a call and handling them immedidately means that your code doesn't continue running in a potentially unstable state. This will make your code more robust and secure. + Checking for errors at the point of a call and handling them immediately means that your code doesn't continue running in a potentially unstable state. This will make your code more robust and secure. diff --git a/4-secure-your-development-environment.md b/4-secure-your-development-environment.md index c6dc74c..0802da1 100644 --- a/4-secure-your-development-environment.md +++ b/4-secure-your-development-environment.md @@ -18,12 +18,11 @@ Where this is the case, it's important to recognise the onward impact that a com ### Security gained -By performing the functions outlined in subsequent sections, you can help reduce the risk of an attacker: +You can take actions to secure your development environment and reduce the risk of an attacker: -* stealing sensitive information (such as encryption and access keys, passwords or knowledge of security controls) +* stealing sensitive information (such as encryption and access keys, passwords, knowledge of security controls or intellectual property) * embedding malicious code in your project without your knowledge -* using a compromised development device as a proxy to further attack your build and deployment pipeline, through to production -* stealing code for the intellectual property it contains, or to release it publicly, causing embarrassment or degrading your security +* using a compromised development device as a proxy to further attack your build and deployment pipeline, through to production * understanding how your sensitive applications work - a first step in the planning of an attack ### Securing a flexible system @@ -44,7 +43,7 @@ The following measures can help you to understand and reduce these risks: If an attacker is able to compromise a developer's environment they will inherit the same level of permissions and access as that developer. Placing additional controls between your developer environments and critical systems will help to reduce this impact. - For example, the use of multi-factor authentication will make it harder for an attacker to leverage stolen credentials and access tokens. Automated security testing and a multi-person review process as part of your deployment pipeline can help catch and prevent onward impact. + For example, the use of multi-factor authentication will make it harder for an attacker who has compromised a device to leverage stolen keys, credentials and access tokens. Automated security testing and a multi-person review process as part of your deployment pipeline can help catch and prevent onward impact. * **Trust your developers, verify their actions** @@ -56,7 +55,7 @@ The following measures can help you to understand and reduce these risks: ## Actions * **Provide developers with the tools and environment they need** - Practical tooling is essential if you want to avoid technically savvy developers finding insecure workarounds. This may sometimes mean being a bit more tolerant to the risks of a developer device being compromised and putting wider protections in place to account for this. If an IT department can respond effectivley to software requests, it may be possible to avoid giving out local administrative permissions. + Practical tooling is essential if you want to avoid technically savvy developers finding insecure workarounds. This may sometimes mean being a bit more tolerant to the risks of a developer device being compromised and putting wider protections in place to account for this. If an IT department can respond effectively to software requests, it may be possible to avoid giving out local administrative permissions. * **Trust your developers, verify their actions** Educate users and trust them to do the right thing. Implement functions to verify their activity, and to detect suspicious activity or potential compromise. @@ -77,7 +76,7 @@ The following measures can help you to understand and reduce these risks: In the event that developer devices are compromised, constrain their onward access with wider network architecture controls that supports defence in depth. Examples may include firewall rule sets only permitting developer devices to communicate to intended services. Also consider the impact these services have on your developers. For example, non transparent proxies can hinder use of some technologies. * **Carry out protective monitoring of your development environment** - You should have an idea of what legitimate use of your environment looks like. Combining this knowledge with logging from your environment can help to detect illegitimate use or potentially, a compromise. For example, are strange websites being accessed and are priviledged actions being carried out during unusual hours of the day? + You should have an idea of what legitimate use of your environment looks like. Combining this knowledge with logging from your environment can help to detect illegitimate use or potentially, a compromise. For example, are strange websites being accessed and are privileged actions being carried out during unusual hours of the day? ## Self assessment diff --git a/5-protect-your-code-repository.md b/5-protect-your-code-repository.md index 8746d58..a7f2b47 100644 --- a/5-protect-your-code-repository.md +++ b/5-protect-your-code-repository.md @@ -14,8 +14,8 @@ Version control, peer review and built-in auditing are some of the advantages wh * **Choose a repository you trust** Consider how the repository itself is administered and managed, including the underlying infrastructure. If the security of these components is compromised, it is difficult to assert trust in the code you store on it. If the repository is managed by a service provider, consider it against the NCSC [Cloud Security Principles](https://www.ncsc.gov.uk/guidance/cloud-security-collection). Layering a process of cryptographic signing and verifying code on top of the repository can help to increase confidence that the code has not been tampered with. -* **Limit exposure & access to your repository** - Technically enforce a model of least privilege for who can read and make changes to your code repository. Only permitted individuals should be able to view and make changes, and all activity should be attributable. For some use cases, it may be appropriate to 'code in the open', but consider the impacts first. +* **Consider the exposure of your repository** + Technically enforce a model of least privilege for who can make changes to your code repository. Make sure all activity is attributable. * **Protect access credentials** User access to repositories is often authenticated using credentials, such as passwords or private keys. Loss of these credentials may allow an attacker to gain unauthorised access. Ensure that developers are encouraged to protect these credentials while they are used and managed within your development environment. Private keys should be password protected. Backing them onto a hardware token such as a [FIDO](https://fidoalliance.org/specifications/overview/) U2F Security Key makes them harder to abuse. Consider the option of rotating access keys. @@ -26,8 +26,8 @@ Version control, peer review and built-in auditing are some of the advantages wh * **Access to the repository should be revoked swiftly when no longer required, or in the event of compromise** As your team evolves over time it's crucial you stay on top of who should have access and who should not. -* **When making code open, carefully consider whether any parts should remain confidential** - Although open-sourcing of code provides many benefits, it may also have a security impact. For example, code used to detect attacks would be of particular benefit to an adversary wishing to evade such measures. Attackers may also be able to glean information useful in formulating a spear-phishing attack. Some of your code may be more appropriately stored in a private repository. +* **Include open code in your risk model** + Some of your code may be more appropriately stored in a private repository. For example, code used to detect fraud attacks would be of particular benefit to an adversary wishing to avoid such measures. When coding in the open, there are a number of security best practices you can adopt, like automated testing and peer reviews. * **Review all code changes** Certain code repositories or branches will hold the source code from which production deployments are made. Ensure that all code merged into this master version has gone through a review process to help prevent unintended or malicious code being included. @@ -40,7 +40,7 @@ Version control, peer review and built-in auditing are some of the advantages wh * **Ensure your code is backed up** Back up your code so it can be restored if anything bad happens to your repository. - + ## Self assessment @@ -53,7 +53,7 @@ These examples are intended to help you assess your own practices, and those of | Code used to detect cyber compromise is published on a public code repository, giving attackers the ability to inspect how it works. |The code repository service chosen was given careful consideration (e.g. using the [Cloud Security Principles](https://www.ncsc.gov.uk/guidance/cloud-security-collection) to understand the risks of different options). | | Your code repository, hosted as a cloud service, adheres to bad security practices. | All code is reviewed before it is merged into the master version of the code repository. Extra care is taken if these code changes were submitted by an individual outside the development team. | | Leavers' accounts and permissions are not deleted or revoked. | Access to source code repositories is joined up with the leavers and joiners process of your organisation. | -| Public profiles of key developers contain a large amount of personal information which could be used by an attacker to mount a convincing spear-phishing attack. | The accounts that developers use to access and modify your organisation's source code are periodically reviewed to assess potential risk. For example, through the public information available to an attacker and the security settings that are used on the accounts. | +| Public profiles of key developers contain a large amount of personal information which could be used to mount a convincing spear-phishing attack. | The accounts that developers use to access and modify your organisation's source code are periodically reviewed to assess potential risk. For example, through the public information available to an attacker and the security settings that are used on the accounts. | ## Related advice diff --git a/6-secure-the-build-and-deployment-pipeline.md b/6-secure-the-build-and-deployment-pipeline.md index 2b85676..c2cb698 100644 --- a/6-secure-the-build-and-deployment-pipeline.md +++ b/6-secure-the-build-and-deployment-pipeline.md @@ -47,10 +47,10 @@ When considering build and deployment security there is an initial question you Consider how your automated build and test tooling react to branches of your code or pull requests that may be malicious. For example, an attacker may be able to execute malicious code within your environment if your automated tooling runs over third party pull requests. * **Be cautious of importing third party libraries and their updates** - Ensure only intended dependencies are included and that they come from legitimate sources. Old versions of libraries may contain security vulnerabilities that will affect your own code. Keep in mind that if you import vulnerable code that it can make your system vulnerable too. + Ensure only intended dependencies are included and that they come from legitimate sources. Old versions of libraries may contain security vulnerabilities that will affect your own code. Keep in mind that if you import vulnerable code, this can make your system vulnerable too. * **Consider hard breaks and approval (optional)** - Fully automated deployment without adequate security controls in place is high risk. If you don't have confidence in the deployment pipeline processes, consider a hard break that requires approval before releases go live into a production environment. + Fully automated deployment without adequate security controls in place is high risk. If you don't have confidence in the deployment pipeline processes, consider a hard break that requires approval before releases go live in a production environment. ## Self assessment diff --git a/7-continually-test-your-security.md b/7-continually-test-your-security.md index 35b809d..4285516 100644 --- a/7-continually-test-your-security.md +++ b/7-continually-test-your-security.md @@ -74,7 +74,7 @@ We have [guidance specifically dedicated to penetration testing](https://www.ncs Automated tests help prevent an issue being re-introduced. * **Expose results of testing to your developers** - Being able to easily view, understand and discuss the outputs of security testing helps you respond to issues, shares knowledge through the team, and reinforces the importance of the test themselves. Examples may include visual displays or interactions with communication channels, such as 'chat-ops'. When tests are not working to support the development process, iterate them. + Being able to easily view, understand and discuss the outputs of security testing helps you respond to issues, shares knowledge through the team, and reinforces the importance of the tests themselves. Examples may include visual displays or interactions with communication channels, such as 'chat-ops'. When tests are not working to support the development process, iterate them. * **Focus security specialists on testing that cannot be easily automated** Automated security testing reduces the burden of repetitive tasks but it doesn't replace manual security audits by skilled professionals. diff --git a/8-plan-for-security-flaws.md b/8-plan-for-security-flaws.md index 7cfe52d..f2867e5 100644 --- a/8-plan-for-security-flaws.md +++ b/8-plan-for-security-flaws.md @@ -4,7 +4,7 @@ All but the very simplest software is likely to contain bugs, some of which may have a security impact. This is true of code written in-house as well as any [third-party resources on which your product relies](3-produce-clean-and-maintainable-code.md). Flaws are not limited to coding errors and implementation mistakes, they can include architectural and design issues too. -Having accepted the inevitability of such problems, make a plan to find and fix them. +Having accepted the inevitability of such problems, [make a plan to find and fix them.] (https://www.ncsc.gov.uk/guidance/vulnerability-management). ### Security debt @@ -14,7 +14,7 @@ Some of this technical debt may have a security impact (for example, granting fu Keeping a register of these items as you go along is important. It will allow you to return and address them later. Consider how 'expensive' the [design decisions](https://www.ncsc.gov.uk/guidance/security-design-principles-digital-services-main) you make today will be later down the line. -## Guidance +## Actions * **Put [vulnerability management](https://www.ncsc.gov.uk/guidance/vulnerability-management) processes in place** Where you use widely available software and hardware, you should be deploying patches and looking for known weak configurations. @@ -29,7 +29,7 @@ Keeping a register of these items as you go along is important. It will allow yo After any event, carry out a [post-mortem](https://landing.google.com/sre/book/chapters/postmortem-culture.html) to help iterate your procedures and adapt your code. Sometimes it's possible to mitigate a whole class of vulnerabilities rather than having to do 'whack-a-mole' for each one. When possible, address the root cause. Seek out the point where the issue was introduced so you can learn from it. * **Provide a way for others to disclose security flaws to you** - It should be possible for users and researchers to responsibly disclose security issues to you. This should be seen as a positive action - an attacker could have used the issue to do harm. + It should be possible for users and researchers to [responsibly disclose](https://www.ncsc.gov.uk/blog-post/vulnerability-co-ordination-pilot) security issues to you. This should be seen as a positive action - an attacker could have used the issue to do harm. * **Feed findings back into the [testing process](7-continually-test-your-security.md)** Creating security tests for issues identified helps to gain confidence they will not occur again. diff --git a/README.md b/README.md index 4d11201..d0d045f 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # Principles of secure development & deployment -> 8 Principles to help you improve and evaluate your development practices, or those of your suppliers. +> 8 Principles to help you improve and evaluate your development practices, and those of your suppliers. > ALPHA: This document is an initial draft. Due to the nature of the guidance, it seemed appropriate to share this on GitHub. We welcome your feedback through issues and pull requests. Please [read our blog](https://www.ncsc.gov.uk/blog-post/secure-development-and-deployment) that introduces this content. @@ -9,13 +9,13 @@ ## Introduction -Having a secure approach to development has never been so important. +Having a secure approach to development has never been so important. The way we build software and systems is rapidly evolving, becoming more and more automated and integrated. Today, developers can define an entire system architecture in code and tie it to tooling which will automate both testing and deployment. Thanks in large part to the arrival of cloud computing and 'infrastructure as code', systems of almost any size and complexity can be called into life, changed or terminated without leaving the desktop. On top of these new capabilities a process of quick and regular deployments has evolved. Often referred to as Continuous Delivery, this iterative approach is powerful, flexible and efficient. -But, these strengths bring with them a new set of risks which your security practices must address. To do so, you will need to consider security as a primary concern throughout the development and deployment process. If you do, the systems, features and fixes you build are less likely to be undermined by security compromise. +But, these strengths bring with them a new set of risks which your security practices must address. To do so, you will need to consider security as a primary concern throughout the development and deployment process. In fact, development & deployment should be a cornerstone of your risk management and threat modelling approach. If you work in this way, the systems, features and fixes you build are less likely to be undermined by security compromise. ### What does this guidance do? @@ -27,9 +27,9 @@ IT systems rarely stand still, they change over time. With that in mind, these p ### Who is this guidance for? -The simple answer is everyone involved in software development and procurement. These principles are intended to help secure the entire process of software development, from establishing a security-friendly culture in your organisation, through to implementation and ongoing management. Whether you're securing a digital service or a traditional application, these criteria will help you gauge the security maturity of your own, or a supplier's development team, and the products and services you are producing or procuring. +The simple answer is everyone involved in software development and procurement. These principles are intended to help secure the entire process of software development, from establishing a security-friendly culture in your organisation, through to implementation and ongoing management. Whether you're securing a digital service or a traditional application, these criteria will help you gauge the security maturity of your own, or a supplier's development team, and the products and services you are producing or procuring. -Using these principles does not guarantee a secure product, but should help you gain confidence that the code you deploy is free from malicious interference. It is also not intended as a list of compliance standards - relevant parts may be pragmatically selected and used at your discretion. +Using these principles does not guarantee a secure product, but should help you gain confidence that the code you deploy is free from malicious interference and fits with your [buisness risk managment stratagy](https://www.ncsc.gov.uk/blog-post/coming-soon-new-guidance-risk-management-cyber-security). It is also not intended as a list of compliance standards - relevant parts may be pragmatically selected and used at your discretion. > If you're developing a product that handles particularly sensitive information (eg information classified at SECRET or TOP SECRET), you should seek additional specialist advice about the specific threats you need to consider. @@ -45,7 +45,7 @@ Development teams, technologies and good practices evolve over time, so you shou ## 8 Principles of Secure Development & Deployment ### 1. Secure development is everyone's concern -Everyone should accept that the security of IT systems is important. Even the most amazing application, delivered on time and to budget, is likely to have security vulnerabilities. A culture which values and rewards the detection and mitigation of these vulnerabilities is the most efficient and effective way to manage this 'fact of life'. Everyone building and running a service has a responsibility for security. +Everyone should accept that the security of IT systems is important. Even the most amazing application, delivered on time and to budget, is likely to have security vulnerabilities. Having a culture which values and rewards the detection and mitigation of these vulnerabilities is the most efficient and effective way to manage this 'fact of life'. Everyone building and running a service has a responsibility for security. [Read more](1-secure-development-is-everyones-concern.md)