├── .gitignore ├── Dockerfile ├── LICENSE ├── README.md ├── docs ├── assets │ └── images │ │ ├── covers │ │ └── default.png │ │ ├── headers │ │ ├── building_empathy.png │ │ ├── home.png │ │ ├── introduction.png │ │ ├── resources.png │ │ ├── secure_sdlc.png │ │ ├── shift_left.png │ │ ├── team_interactions.png │ │ ├── terminology.png │ │ └── training.png │ │ └── six-pillars-of-devsecops-secure-sdlc-diagram.png ├── culture │ ├── building_empathy.md │ └── team_interactions.md ├── implement │ ├── shift_left.md │ └── training.md ├── index.md ├── introduction.md ├── markdown.md ├── resources.md ├── secure_sdlc.md └── terminology.md ├── mkdocs.yml ├── netlify.toml ├── requirements.txt ├── runtime.txt └── screenshot.png /.gitignore: -------------------------------------------------------------------------------- 1 | .smbdelete* 2 | -------------------------------------------------------------------------------- /Dockerfile: -------------------------------------------------------------------------------- 1 | # https://circleci.com/docs/2.0/circleci-images/#python 2 | # We may as well use the same image we use for actually deploying our sites. 3 | FROM circleci/python:3.9.2 4 | 5 | # Dependencies 6 | RUN sudo pip install mkdocs 7 | RUN sudo pip install pymdown-extensions 8 | RUN sudo pip install pygments 9 | 10 | # Install the PagerDuty theme. 11 | WORKDIR /tmp 12 | RUN git clone https://github.com/pagerduty/mkdocs-theme-pagerduty 13 | RUN cd mkdocs-theme-pagerduty && sudo python3 setup.py install 14 | 15 | # Set our working directory and user 16 | WORKDIR /docs 17 | RUN sudo useradd -m --uid 1000 mkdocs 18 | USER mkdocs 19 | 20 | # Expose MkDocs server 21 | EXPOSE 8000 22 | 23 | # Start the local MkDocs server. 24 | ENTRYPOINT ["mkdocs"] 25 | CMD ["serve", "--dev-addr=0.0.0.0:8000"] 26 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Copyright 2019 PagerDuty, Inc. 2 | 3 | Apache License 4 | Version 2.0, January 2004 5 | http://www.apache.org/licenses/ 6 | 7 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 8 | 9 | 1. Definitions. 10 | 11 | "License" shall mean the terms and conditions for use, reproduction, 12 | and distribution as defined by Sections 1 through 9 of this document. 13 | 14 | "Licensor" shall mean the copyright owner or entity authorized by 15 | the copyright owner that is granting the License. 16 | 17 | "Legal Entity" shall mean the union of the acting entity and all 18 | other entities that control, are controlled by, or are under common 19 | control with that entity. For the purposes of this definition, 20 | "control" means (i) the power, direct or indirect, to cause the 21 | direction or management of such entity, whether by contract or 22 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 23 | outstanding shares, or (iii) beneficial ownership of such entity. 24 | 25 | "You" (or "Your") shall mean an individual or Legal Entity 26 | exercising permissions granted by this License. 27 | 28 | "Source" form shall mean the preferred form for making modifications, 29 | including but not limited to software source code, documentation 30 | source, and configuration files. 31 | 32 | "Object" form shall mean any form resulting from mechanical 33 | transformation or translation of a Source form, including but 34 | not limited to compiled object code, generated documentation, 35 | and conversions to other media types. 36 | 37 | "Work" shall mean the work of authorship, whether in Source or 38 | Object form, made available under the License, as indicated by a 39 | copyright notice that is included in or attached to the work 40 | (an example is provided in the Appendix below). 41 | 42 | "Derivative Works" shall mean any work, whether in Source or Object 43 | form, that is based on (or derived from) the Work and for which the 44 | editorial revisions, annotations, elaborations, or other modifications 45 | represent, as a whole, an original work of authorship. For the purposes 46 | of this License, Derivative Works shall not include works that remain 47 | separable from, or merely link (or bind by name) to the interfaces of, 48 | the Work and Derivative Works thereof. 49 | 50 | "Contribution" shall mean any work of authorship, including 51 | the original version of the Work and any modifications or additions 52 | to that Work or Derivative Works thereof, that is intentionally 53 | submitted to Licensor for inclusion in the Work by the copyright owner 54 | or by an individual or Legal Entity authorized to submit on behalf of 55 | the copyright owner. For the purposes of this definition, "submitted" 56 | means any form of electronic, verbal, or written communication sent 57 | to the Licensor or its representatives, including but not limited to 58 | communication on electronic mailing lists, source code control systems, 59 | and issue tracking systems that are managed by, or on behalf of, the 60 | Licensor for the purpose of discussing and improving the Work, but 61 | excluding communication that is conspicuously marked or otherwise 62 | designated in writing by the copyright owner as "Not a Contribution." 63 | 64 | "Contributor" shall mean Licensor and any individual or Legal Entity 65 | on behalf of whom a Contribution has been received by Licensor and 66 | subsequently incorporated within the Work. 67 | 68 | 2. Grant of Copyright License. Subject to the terms and conditions of 69 | this License, each Contributor hereby grants to You a perpetual, 70 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 71 | copyright license to reproduce, prepare Derivative Works of, 72 | publicly display, publicly perform, sublicense, and distribute the 73 | Work and such Derivative Works in Source or Object form. 74 | 75 | 3. Grant of Patent License. Subject to the terms and conditions of 76 | this License, each Contributor hereby grants to You a perpetual, 77 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 78 | (except as stated in this section) patent license to make, have made, 79 | use, offer to sell, sell, import, and otherwise transfer the Work, 80 | where such license applies only to those patent claims licensable 81 | by such Contributor that are necessarily infringed by their 82 | Contribution(s) alone or by combination of their Contribution(s) 83 | with the Work to which such Contribution(s) was submitted. If You 84 | institute patent litigation against any entity (including a 85 | cross-claim or counterclaim in a lawsuit) alleging that the Work 86 | or a Contribution incorporated within the Work constitutes direct 87 | or contributory patent infringement, then any patent licenses 88 | granted to You under this License for that Work shall terminate 89 | as of the date such litigation is filed. 90 | 91 | 4. Redistribution. You may reproduce and distribute copies of the 92 | Work or Derivative Works thereof in any medium, with or without 93 | modifications, and in Source or Object form, provided that You 94 | meet the following conditions: 95 | 96 | (a) You must give any other recipients of the Work or 97 | Derivative Works a copy of this License; and 98 | 99 | (b) You must cause any modified files to carry prominent notices 100 | stating that You changed the files; and 101 | 102 | (c) You must retain, in the Source form of any Derivative Works 103 | that You distribute, all copyright, patent, trademark, and 104 | attribution notices from the Source form of the Work, 105 | excluding those notices that do not pertain to any part of 106 | the Derivative Works; and 107 | 108 | (d) If the Work includes a "NOTICE" text file as part of its 109 | distribution, then any Derivative Works that You distribute must 110 | include a readable copy of the attribution notices contained 111 | within such NOTICE file, excluding those notices that do not 112 | pertain to any part of the Derivative Works, in at least one 113 | of the following places: within a NOTICE text file distributed 114 | as part of the Derivative Works; within the Source form or 115 | documentation, if provided along with the Derivative Works; or, 116 | within a display generated by the Derivative Works, if and 117 | wherever such third-party notices normally appear. The contents 118 | of the NOTICE file are for informational purposes only and 119 | do not modify the License. You may add Your own attribution 120 | notices within Derivative Works that You distribute, alongside 121 | or as an addendum to the NOTICE text from the Work, provided 122 | that such additional attribution notices cannot be construed 123 | as modifying the License. 124 | 125 | You may add Your own copyright statement to Your modifications and 126 | may provide additional or different license terms and conditions 127 | for use, reproduction, or distribution of Your modifications, or 128 | for any such Derivative Works as a whole, provided Your use, 129 | reproduction, and distribution of the Work otherwise complies with 130 | the conditions stated in this License. 131 | 132 | 5. Submission of Contributions. Unless You explicitly state otherwise, 133 | any Contribution intentionally submitted for inclusion in the Work 134 | by You to the Licensor shall be under the terms and conditions of 135 | this License, without any additional terms or conditions. 136 | Notwithstanding the above, nothing herein shall supersede or modify 137 | the terms of any separate license agreement you may have executed 138 | with Licensor regarding such Contributions. 139 | 140 | 6. Trademarks. This License does not grant permission to use the trade 141 | names, trademarks, service marks, or product names of the Licensor, 142 | except as required for reasonable and customary use in describing the 143 | origin of the Work and reproducing the content of the NOTICE file. 144 | 145 | 7. Disclaimer of Warranty. Unless required by applicable law or 146 | agreed to in writing, Licensor provides the Work (and each 147 | Contributor provides its Contributions) on an "AS IS" BASIS, 148 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 149 | implied, including, without limitation, any warranties or conditions 150 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 151 | PARTICULAR PURPOSE. You are solely responsible for determining the 152 | appropriateness of using or redistributing the Work and assume any 153 | risks associated with Your exercise of permissions under this License. 154 | 155 | 8. Limitation of Liability. In no event and under no legal theory, 156 | whether in tort (including negligence), contract, or otherwise, 157 | unless required by applicable law (such as deliberate and grossly 158 | negligent acts) or agreed to in writing, shall any Contributor be 159 | liable to You for damages, including any direct, indirect, special, 160 | incidental, or consequential damages of any character arising as a 161 | result of this License or out of the use or inability to use the 162 | Work (including but not limited to damages for loss of goodwill, 163 | work stoppage, computer failure or malfunction, or any and all 164 | other commercial damages or losses), even if such Contributor 165 | has been advised of the possibility of such damages. 166 | 167 | 9. Accepting Warranty or Additional Liability. While redistributing 168 | the Work or Derivative Works thereof, You may choose to offer, 169 | and charge a fee for, acceptance of support, warranty, indemnity, 170 | or other liability obligations and/or rights consistent with this 171 | License. However, in accepting such obligations, You may act only 172 | on Your own behalf and on Your sole responsibility, not on behalf 173 | of any other Contributor, and only if You agree to indemnify, 174 | defend, and hold each Contributor harmless for any liability 175 | incurred by, or claims asserted against, such Contributor by reason 176 | of your accepting any such warranty or additional liability. 177 | 178 | END OF TERMS AND CONDITIONS 179 | 180 | APPENDIX: How to apply the Apache License to your work. 181 | 182 | To apply the Apache License to your work, attach the following 183 | boilerplate notice, with the fields enclosed by brackets "[]" 184 | replaced with your own identifying information. (Don't include 185 | the brackets!) The text should be enclosed in the appropriate 186 | comment syntax for the file format. We also recommend that a 187 | file or class name and description of purpose be included on the 188 | same "printed page" as the copyright notice for easier 189 | identification within third-party archives. 190 | 191 | Copyright [yyyy] [name of copyright owner] 192 | 193 | Licensed under the Apache License, Version 2.0 (the "License"); 194 | you may not use this file except in compliance with the License. 195 | You may obtain a copy of the License at 196 | 197 | http://www.apache.org/licenses/LICENSE-2.0 198 | 199 | Unless required by applicable law or agreed to in writing, software 200 | distributed under the License is distributed on an "AS IS" BASIS, 201 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 202 | See the License for the specific language governing permissions and 203 | limitations under the License. 204 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # PagerDuty DevSecOps Documentation 2 | 3 | [![Netlify Status](https://api.netlify.com/api/v1/badges/56a0b236-13fc-4876-a5a6-da329ae7ae89/deploy-status)](https://app.netlify.com/sites/devsecops-72b1ca/deploys) 4 | 5 | This guide is an introduction to DevSecOps, the cultural practice of integrating the security team into the process flow of development and operations. 6 | 7 | You can view the documentation directly in this repository, or rendered as a website at [devsecops.pagerduty.com](https://devsecops.pagerduty.com): 8 | 9 | [![PagerDuty Best Practices for DevSecOps Guide](screenshot.png)](https://devsecops.pagerduty.com) 10 | 11 | ## Development 12 | We use [MkDocs](http://www.mkdocs.org/) to create a static site from this repository. 13 | 14 | ### Native 15 | For local development on your native device, 16 | 17 | 1. Install [MkDocs](http://www.mkdocs.org/#installation). `pip install mkdocs` 18 | 1. Install [MkDocs PyMdown Extensions](https://squidfunk.github.io/mkdocs-material/extensions/pymdown/). `pip install pymdown-extensions` 19 | 1. Install [Pygments](https://pygments.org/) if you want syntax highlighting for any code examples. `pip install pygments` 20 | 1. Install the [PagerDuty MkDocs Theme](https://github.com/pagerduty/mkdocs-theme-pagerduty). 21 | 1. `git clone https://github.com/pagerduty/mkdocs-theme-pagerduty` 22 | 1. `cd mkdocs-theme-pagerduty & python3 setup.py install` 23 | 1. To test locally, run `mkdocs serve` from the project directory. 24 | 1. You can now view the website in your browser at `http://127.0.0.1:8000`. The site will automatically update as you edit the code. 25 | 26 | ### Docker 27 | For local development using Docker, 28 | 29 | 1. Build the docker image and load it for immediate use. `docker build --load -t mkdocs .` 30 | 1. Run the container and pass through your current working directory. `docker run -v $(pwd):/docs -p 127.0.0.1:8000:8000 mkdocs` 31 | 1. You can now view the website in your browser at `http://127.0.0.1:8000`. The site will automatically update as you edit the code. 32 | 33 | _Note: If you're using an Apple Silicon device, add `--platform linux/arm64/v8` to the `docker build` command to get a native Apple Silicon image. That will work faster than translating an arm64 image._ 34 | 35 | ## Deploying 36 | 1. Run `mkdocs build --clean` to produce the static site for upload. 37 | 1. Upload the `site` directory to S3 (or wherever you would like it to be hosted). 38 | 39 | aws s3 sync ./site/ s3://[BUCKET_NAME] \ 40 | --acl public-read \ 41 | --exclude "*.py*" \ 42 | --delete 43 | 44 | ## License 45 | [Apache 2](http://www.apache.org/licenses/LICENSE-2.0) (See [LICENSE](LICENSE) file) 46 | 47 | ## Contributing 48 | Thank you for considering contributing! If you have any questions, just ask - or submit your issue or pull request anyway. The worst that can happen is we'll politely ask you to change something. We appreciate all friendly contributions. 49 | 50 | Here is our preferred process for submitting a pull request, 51 | 52 | 1. Fork it ( https://github.com/PagerDuty/devsecops-docs/fork ) 53 | 1. Create your feature branch (`git checkout -b my-new-feature`) 54 | 1. Commit your changes (`git commit -am 'Add some feature'`) 55 | 1. Push to the branch (`git push origin my-new-feature`) 56 | 1. Create a new Pull Request. 57 | -------------------------------------------------------------------------------- /docs/assets/images/covers/default.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PagerDuty/devsecops-docs/8f3941c9cddd219d1fad11552f6852da010613d2/docs/assets/images/covers/default.png -------------------------------------------------------------------------------- /docs/assets/images/headers/building_empathy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PagerDuty/devsecops-docs/8f3941c9cddd219d1fad11552f6852da010613d2/docs/assets/images/headers/building_empathy.png -------------------------------------------------------------------------------- /docs/assets/images/headers/home.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PagerDuty/devsecops-docs/8f3941c9cddd219d1fad11552f6852da010613d2/docs/assets/images/headers/home.png -------------------------------------------------------------------------------- /docs/assets/images/headers/introduction.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PagerDuty/devsecops-docs/8f3941c9cddd219d1fad11552f6852da010613d2/docs/assets/images/headers/introduction.png -------------------------------------------------------------------------------- /docs/assets/images/headers/resources.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PagerDuty/devsecops-docs/8f3941c9cddd219d1fad11552f6852da010613d2/docs/assets/images/headers/resources.png -------------------------------------------------------------------------------- /docs/assets/images/headers/secure_sdlc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PagerDuty/devsecops-docs/8f3941c9cddd219d1fad11552f6852da010613d2/docs/assets/images/headers/secure_sdlc.png -------------------------------------------------------------------------------- /docs/assets/images/headers/shift_left.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PagerDuty/devsecops-docs/8f3941c9cddd219d1fad11552f6852da010613d2/docs/assets/images/headers/shift_left.png -------------------------------------------------------------------------------- /docs/assets/images/headers/team_interactions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PagerDuty/devsecops-docs/8f3941c9cddd219d1fad11552f6852da010613d2/docs/assets/images/headers/team_interactions.png -------------------------------------------------------------------------------- /docs/assets/images/headers/terminology.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PagerDuty/devsecops-docs/8f3941c9cddd219d1fad11552f6852da010613d2/docs/assets/images/headers/terminology.png -------------------------------------------------------------------------------- /docs/assets/images/headers/training.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PagerDuty/devsecops-docs/8f3941c9cddd219d1fad11552f6852da010613d2/docs/assets/images/headers/training.png -------------------------------------------------------------------------------- /docs/assets/images/six-pillars-of-devsecops-secure-sdlc-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PagerDuty/devsecops-docs/8f3941c9cddd219d1fad11552f6852da010613d2/docs/assets/images/six-pillars-of-devsecops-secure-sdlc-diagram.png -------------------------------------------------------------------------------- /docs/culture/building_empathy.md: -------------------------------------------------------------------------------- 1 | ![Building Empathy](/assets/images/headers/building_empathy.png) 2 | 3 | It’s hard to develop empathy for another person, team, or discipline when you haven’t “walked a mile in their shoes.” Unfortunately, this is quite common for developers, operations specialists, and security specialists—how many former security professionals are working in development or vice versa, for example? To compound the issue, when empathy isn’t present, people have a difficult time understanding each other, which can create a lot of friction in professional relationships. At the beginning of the DevOps transformation, there was a lot of friction that existed between the developer and operations teams that impeded their work, which compounded the delays caused by siloed workstreams. Much later, streamlined workflows and common understanding has greatly improved their working relationships; however, security teams have frequently been left out of the DevOps transformation. As a result, these relationships haven’t flourished as much as they could. 4 | 5 | DevSecOps is a new iteration of a familiar initiative, this time including security in the SDLC as opposed to finding themselves inundated with requests after all the code is written and likely needing to be changed. This initiative will also help developers and operators as well—just like DevOps required developers to be op-aware and operators to be dev-aware, DevSecOps requires all three groups to be aware of each other’s interdependencies and needs. 6 | 7 | The foundation of this transformation is all the people involved. To that end, when you are looking to shift to a DevSecOps culture, you’ll need to look to the people first and the processes that support them second. As such, this guide starts by covering how to support developers, operators, and security professionals working together in a way they have not before—by building relationships, empathy, and trust. Then, we will proceed to discuss the beginning knowledge for how to shift security left within the SDLC. 8 | 9 | ## Walk A Mile: Shadowing 10 | At PagerDuty, [we shadow extensively](https://www.pagerduty.com/blog/on-call-shadow-practice/) for training purposes. In the context of DevSecOps, having each of the teams shadow with each other will similarly allow them to develop both empathy and understanding for what the workflow is like for the other teams. 11 | 12 | For security, shadowing can mean sitting in with the development and/or operations team for a sprint. This could happen on a rotation—so for every sprint, one person from the security team would sit in with development or operations. Make sure to configure this on a rotation that makes sense for both teams. In the event of an incident, the shadowee should continue to shadow for as long as it makes sense, as there is a lot to be learned when a team is in “crisis mode.” That being said, if the incident evolves in such a way that the shadowee’s subject matter expertise is needed, then they should resume that role. 13 | 14 | Similarly, developers and operations specialists can shadow security to learn more about their workflow. The important caveat here is that, typically, security team members have more access globally than most other teams, so it’s important when shadowing to ensure that the shadowee is not granted increased access or permissions unless it is appropriate. 15 | 16 | ## Full-Service Ownership 17 | Here at PagerDuty, we talk a lot about [Full-Service Ownership](https://ownership.pagerduty.com/) (FSO), and relatedly another way that security teams can learn about the production process to actually own a Tier 1 or 2 (critical) service that makes business sense. For example, if your business or organization uses a tool to manage secrets, tokens, etc., it might make sense for the security team to own that service. Under the FSO model, the security team would own the revision, upgrade/update, and release cycle for that service, as well as the on-call rotation for that service. Similarly, having a dev or ops team own a security service or process that will provide insight into how security works as well as have the team responsible for some of the same end goals as the security team. 18 | 19 | It is important to choose services in either scenario that is both feasible and makes good business sense. For example, development and/or operations should not own a service that would require an escalation in their privileges and security should not own a service that requires support that is outside of their expertise. Luckily, most architectures require multiple services so in these cases another, more prudent, service can and should be chosen. 20 | 21 | When choosing a service, make sure to avoid partial or shared service ownership as this can cause confusion or create gaps in process. For example, if Service A is owned by Teams 1 & 2, how are upgrades performed? Is approval needed from both? What happens if an update has a feature needed by one team, but has backwards breaking changes for the other? If both teams own the service, then it will be difficult to have a consensus. As a last example, which team is responsible for handling incidents and issues related to the service? If only one team is required for any of these tasks, then the other team may be caught off guard or resent not being included in the discussion and/or decision. When there is one owner, then while they still need to consider the needs of everyone using the service, there is still one team that needs to make the final decisions as well as handle issues. 22 | 23 | ## Security Champions Program 24 | Bottlenecks frequently cause friction between the development, operations, and security teams. In order to improve cross-team communication, these teams need a regularly scheduled time to discuss important issues and updates with each other. A Security Champions Program does just that. The program would be facilitated by members of the security team, but participants would come from development, operations, and any other teams that make sense. The meeting will allow the various participants to update each other about different messaging, changes, updates, and other topics that they want brought back to each department. 25 | 26 | Similar to other programs or resource groups that you might run in your company, you will need buy-in from different stakeholders to set the program up for success. In this case, you’ll be looking at not only the agreement for a few key people in various departments who will hopefully attend the meetings, but also executives and management. You’ll also need a good understanding of the security culture at your organization to facilitate the meetings, even if you are not a security specialist. 27 | 28 | For who should attend the meeting, start with your knowledge of your current culture. Use this to define what and who should be in the initial meetings to gain traction as well as show value to other people and teams that you’d like to include. In the meeting, you’ll want to make sure that there is adequate time for everyone to give the updates they need to give, ask the questions of each other that they need to ask. This can initially start with development, operations, and security but should eventually extend beyond these groups. For example, someone who works with customers directly would benefit from being able to handle some starter security questions before deferring to an expert on the security team itself. 29 | 30 | ## Meet Needs to Gain Momentum 31 | Depending on the existing company structure and culture, it is possible that security is viewed as a “necessary hindrance”. This could be for a variety of reasons, but some are at least partly due to the issues you’re here to solve: breaking down silos that can cause slowness and breakdowns in communication. Of course, the reality is that security, like development and operations, is an incredibly interesting and complex field that protects customers and users as well as gaining and maintaining their trust. 32 | 33 | If this is where you’re starting from, never fear! The first step here is to start to reverse this mindset. To begin: identify both the stakeholders and the teams that you’ll be working with the most. Start having meetings with people in these groups and look to identify their needs. The needs may not, at first, be immediately relevant to security but still overlap with your security team’s expertise. Have them work on the issues that are being raised by the other stakeholders and teams. This will start to build the human connections between the humans of security, operations, and development. 34 | 35 | While this work is ongoing, the security team can start to seed some better practices as they move forward. The idea here is to add value, especially where there are gaps. There is also an opportunity to “make it easy to do the right thing”. For example, if security is helping improve workflows while also making them more secure. The team that is implementing that change should see the benefit to themselves, but the new security layer(s) in the workflow should not add complexity. Building up these use cases, the team should be able to align their work with some combination of the company’s mission statement, goals, and/or KPIs. The caveat to this is to use good judgement: the security team can and should be empowered to take action with any current security incidents or any high risk vulnerabilities that need to be urgently addressed. 36 | -------------------------------------------------------------------------------- /docs/culture/team_interactions.md: -------------------------------------------------------------------------------- 1 | ![Team Interactions](/assets/images/headers/team_interactions.png) 2 | 3 | Team interactions rely on common communication tools and techniques. In general, development, operations, and security teams should use as many common tools as possible. This will help each team streamline communication with each other as well as keep all the various teams’ activities transparent to each other. Explicitly, as a minimum, make sure that the teams are using the same email, chat, and ticketing systems. 4 | 5 | Beyond tooling, there are a few standards of practice that the teams can implement that will improve not only communication but awareness of the different needs and expectations of each team. 6 | 7 | 1. **Meetings** 8 | * Have regular meetings between the teams, such as regular standups. Depending on the size of the teams, this might be everyone in one meeting or representatives from each of the teams in a separate meeting, bringing back what they learn to their respective teams. 9 | 1. **Rules for Tools** 10 | * Set expectations for how the different teams prefer to communicate and with what level of urgency. Again, it is best to keep these as similar between the teams as possible. This might be something like chat for when a quick response is needed, or email for a slower, less-urgent response. 11 | 1. **Rules of Engagement** 12 | * Including and beyond tools, there should also be a “Rules of Engagement.” This will help guide other situations including, but not limited to: when to have meetings, whether cameras are on or off, if and when people should mute, how to determine who the next speaker is, and so on. We have a template available for Rules of Engagement here to help you get started. **[Here is one of the templates we use at PagerDuty](https://docs.google.com/presentation/d/1N4mAtI9Yaw1ZX0AkkyStJ41HwDgj__Kg3tQQgMHo1SA/edit?usp=sharing)**. 13 | 1. **Documentation** 14 | * Documentation can help avoid a lot of communication breakdowns. Remember, most developers and operations specialists have not worked in security and vice versa. Since each group cannot necessarily intuit what the appropriate level of context to provide when sending requests back and forth, it is important for each group to document what they need with extra granularity for the most common requests to function as a template. This will provide all groups with a reference to send information to each other and prevent things from being forgotten, which can lead to mutual frustration. To get started with this, document the request flow for each request as it arises and each iteration as the process improves. 15 | 1. **Review and Iterate** 16 | * As you build new processes and procedures, always verify that they are working as intended and make changes as needed. This includes meetings, structures, documents, and so forth. This should be done at a frequency that makes sense—for example, if you’re reviewing a daily standup, you might want to review weekly; however, if you’re reviewing a bi-weekly sprint, you might want to do a quick process review at the end of each meeting. 17 | 18 | Even with the most robust communication process, there will still be communication breakdowns. This can be in either direction, typically either due to malformed or misrouted requests, and can be inflamed if there is a short deadline or active incident that needs to be resolved. When these situations happen, it’s best to try and resolve quickly, amicably, and without judgement. For more details around this communications approach, take a look at the [4-Part Nonviolent Communication Process](https://www.nonviolentcommunication.com/pdf_files/4part_nvc_process.pdf), which templates how to ask questions in a non-judgemental way. 19 | -------------------------------------------------------------------------------- /docs/implement/shift_left.md: -------------------------------------------------------------------------------- 1 | ![Shift Security Left](/assets/images/headers/shift_left.png) 2 | 3 | Simply put: shifting security left means integrating security earlier in the SDLC. This is a different approach to how security is currently implemented, where their team is mostly reacting to a current incident, or being consulted as a last-step before something is released to production. Looking at the latter case first for a moment, that means that any insecure code that was designed and implemented has made it through the entire lifecycle before being reviewed. If security finds an issue, that means changes are likely to go back around the full cycle again before going live in production. 4 | 5 | When security issues are found they require not only modifications to the codebase, but also other changes elsewhere in the life cycle (e.g. updating tests, monitoring, etc.). Shifting security left allows teams to address security issues much earlier in the life cycle, rather than finding out after significant labor has already taken place. 6 | 7 | Shifting security left is a series of tasks—it is not meant to be something that you implement quickly. Just like all other changes in IT, the best way to proceed is with small changes, reviews, and iterations. You will need to start with a security assessment, perform organizational training and exercises to improve your security posture. For reference, there is also a list of security actions and tests at different phases (or stages) in the SDLC at the end of the section. 8 | 9 | ## Identify Your Needs With a Security Assessment 10 | 11 | Before you can begin shifting left, you need to know your current status. You might think of this as the “security health” of your org, and the industry term for this is your “security posture.” Specifically, security posture is defined as: 12 | 13 | * Security posture refers to an organization's overall cybersecurity strength and how well it can predict, prevent and respond to ever-changing cyberthreats. ([Source](https://searchsecurity.techtarget.com/definition/security-posture)) 14 | 15 | Why look at your security posture? The main goal is to provide some context for how you should proceed when you shift left. Should you move slowly from right to left across the SDLC, implementing tests and procedures as you go? Should you fix forward and choose a project that starts with security considerations from the design phase? Or should you choose an approach that is a hybrid of the above options? 16 | 17 | The answer is that it depends and can vary widely. The best way forward is to “meet yourself where you’re at.” The security assessment will provide information that you can use to determine your next steps. Specifically, the security assessment should inform you of any current security risks and their criticality. Some questions the assessment will need to address: 18 | 19 | * Have there been any security incidents? 20 | * What are your current risks? 21 | * How critical are they? 22 | 23 | Once you have this information, the first questions you should discuss with your security team are: 24 | 25 | * Which security incidents that are at risk of repeating can be resolved with changes to security procedures? 26 | * What critical risks can be mitigated or resolved by changing security procedures? 27 | 28 | Resolving current or likely security incidents should be the first priority as you shift left. After these are addressed, you’ll want to start focusing on ways that you can build momentum and show the value by choosing those courses of action that will be “high value, low lift.” Translated into something more actionable, this means the development, operations, and security teams will need to work together to find which changes in security procedure have a high impact by influencing multiple factors—while minimizing how much customization is required. As you build momentum and the benefit of shifting left is more tangible, you can iterate more changes to improve your overall security posture. 29 | 30 | ## Assessment Frameworks 31 | 32 | How to decide which assessment(s) to run, and executing them, is under the purview of your security team. That said, there are some frameworks that you can take a look at to have a better understanding of what goes into assessments in general to know what roughly to expect. These frameworks can also help establish a starting point for your own assessments, rather than your team customizing one from scratch. Some common frameworks include: 33 | 34 | * [DSOMM](https://owasp.org/www-project-devsecops-maturity-model/) (OWASP’s DevSecOps Maturity Model) 35 | * [BSIMM](https://www.bsimm.com/) (Building Security In Maturity Model) 36 | * [SAMM](https://owasp.org/www-project-samm/) (OWASP’s Software Assurance Maturity Model) 37 | * [NIST’s Infrastructure Security Framework](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf) 38 | 39 | If your company is part of a regulated industry, you’ll also want to verify if there are frameworks available that tailor to that industry. For example, Qualys is an approved vendor for PCI compliance and offers a web vulnerability scanner to help organizations become compliant. 40 | -------------------------------------------------------------------------------- /docs/implement/training.md: -------------------------------------------------------------------------------- 1 | ![Training for Engineers](/assets/images/headers/training.png) 2 | 3 | ## Threat Modeling Exercises 4 | 5 | This is similar to the exercises that developers and operators do for production, such as running chaos experiments (at PagerDuty we’ve been doing [Failure Fridays](https://www.pagerduty.com/blog/failure-friday-at-pagerduty/) for [years](https://www.pagerduty.com/blog/failure-fridays-four-years/)). These exercises allow teams of both disciplines to really understand the interdependencies of our complex systems. Threat modeling is a similar idea. The goal of threat modeling is to consider the security implications of your environment, including but not limited to the code written, the services running, and overall test coverage. In the DevSecOps model, at a minimum, you’ll need all three teams—development, operations, and security—to gather and contribute within their areas of expertise. 6 | 7 | But how do you get started? Take a look at the [STRIDE](https://en.wikipedia.org/wiki/STRIDE_(security)) framework for threat modeling. The acronym stands for: 8 | 9 | * **Spoofed identity** 10 | * This is when someone who does not have an identity is able to access that identity, for example a sysadmin identity, usually to take advantage of resources and/or data that it has access to. 11 | * **Tampering with input** 12 | * Modifying data that has been sent to a system. 13 | * **Repudiation of action** 14 | * Non-repudiation is, generically, the inability to dispute who authored something, or who performed an action. In the context of IT,, this mostly comes up in signatures and audit trails. You want to ensure that logs cannot be tampered with, so you can always ensure that whatever entity is logged as performing an action, did that action, and that actions are logged. 15 | * **Information disclosure** 16 | * When someone is able to access information they should not be able to, like an individual customer’s address (e.g. spoofing as that customer) or payment information, among other things. 17 | * **Denial of service** 18 | * This is when a service, system, or application is flooded with traffic or information with the intent to bring it down (i.e. to deny service). 19 | * **Escalation of privilege** 20 | * When a user or account is able to gain more access to a service, system, or application than was intended by design. 21 | 22 | ThoughtWorks, a software consultancy, created cue cards and other materials to assist if you are interested in using STRIDE. You can find them on their Agile Threat Modeling site [here](https://thoughtworksinc.github.io/sensible-security-conversations/). It’s important to recognize, as mentioned above, that STRIDE is not a complete threat modeling framework, it is a starting point. Some points to consider not covered by STRIDE are how to handle the discovered vulnerabilities, how to rank their risk, how to ensure the resulting work is appropriately prioritized in the backlog, and so forth. To get started with all of these, you’ll be working with your security team and I also recommend leveraging OWASP and NIST materials for additional insight. 23 | 24 | Running a threat modeling session is a lot like other deep-dive meetings, like [postmortems](https://postmortems.pagerduty.com/meeting/) and [retrospectives](https://retrospectives.pagerduty.com/planning/). The goal is to have a meeting that is long enough, while avoiding running too long. Since these meetings are exercises to improve your security posture and mindset, you’ll also want to make sure that you have them on a regular basis. To get started with both, try one hour sessions every other week and iterate from there until you find what works best for your team. Remember that time boxing is important to help everyone retain and put into practice what they have learned. For pacing, make sure the meetings are close enough together that you can continue in the next meeting rather than be tempted to “go into overtime” in your current session. 25 | 26 | ## Capture the Flag Games 27 | 28 | The digital version of the grade school game! A quick recap of the land version for the unfamiliar: capture the flag (CTF) is a game where you capture an item (usually a piece of cloth representing a flag) from the opposite team. 29 | 30 | How does this work with computers? The assignment is usually to get through a vulnerability on a server, website, or similar technology asset to get a piece of information that is supposed to be “the flag.” As a quick example, you might need to access `flag.txt`in the root user’s home directory without being the root user or using sudo, with the file or its contents being “the flag.” 31 | 32 | Various types of CTF games cover a broad range of skills in security. For example: 33 | 34 | * **Forensics** 35 | * Recovering data that was not thoroughly deleted or was logged to a different location. 36 | * **Cryptography** 37 | * Decrypting encrypted data. 38 | * **Web Exploitation** 39 | * Using common exploits like SQL injection or cross site scripting. 40 | * **Reverse Engineering** 41 | * Converting compiled code into a human readable format. 42 | * **Binary Exploitation** 43 | * Using common exploits like buffer overflow or heap overflow. 44 | 45 | The goal of playing these games is to bridge the gap between “I understand this in theory” and “I understand this in application.” Thinking more like an attacker leads to more secure code and infrastructure, as you will be able to understand which attacks are more or less likely as well as how successful they are likely to be. 46 | 47 | 48 | ## Establish Trust: Don’t Do “Gotchas” 49 | 50 | We’ve all seen examples in the news of extraordinarily bad phishing tests done by companies to test their staff that range from humorous to hurtful. The intention is usually to use a socially engineered method that will tempt people to click on these emails similar to the way that attackers do. The result is often that people will open the emails and perhaps even click the links, but when they realize they’ve been internally duped, there’s a loss of trust between them and the security team that is trying to tell staff they’re there to help. 51 | 52 | Instead of tricking staff, educate staff. If certain types of socially engineered attacks are common—like preying on people’s financial, housing, or other vulnerabilities—teach them what those methods are and show them examples in your training sessions. By both showing what to recognize and being approachable, the security team is able to better improve the business’s security posture. 53 | 54 | For emphasis: 55 | 56 | > When staff **trusts** the security team, they are more likely to approach that team when something **does** happen. 57 | 58 | Here at PagerDuty, we have a ***policy not to trick staff, ever***. Common security exploits and methods, including socially engineered attacks, are included in our security trainings. Due to the trust that security has garnered in our organization, staff feel more comfortable approaching security whenever they do discover that they clicked a link from a phishing email or something similar. When things like that happen, security asks clarifying questions, runs a scan on their machine, lets them know of any indicators of compromised security, and then discusses those with them in an accessible way, so the person knows what to do next, if anything. Due to the high degree of trust in our organization, our security team has actually been able to automate a lot around staff reports of security risks, like phishing emails, that were found and reported. 59 | 60 | ## Socially Engineer Security Trainings 61 | 62 | Many of us have needed to sit through pre-recorded security trainings with the goal of improving our ability to navigate common traps in our digital world. That said, many people struggle with these training methods. It’s not uncommon for people to watch them while doing things in the background, or let them play in the background and answer the quiz at the end (if there is one). 63 | 64 | Instead, make your security training engaging. Present about common phishing techniques by showing them—as well as other exploits—but also do things that help engage attendees to keep the content interesting and interactive. In our past security trainings, we’ve shown examples of common passwords exploits in action (demo’ed), as well as “MFA or Not MFA” questions that are instructive for people not familiar with multi-factor authentication. For example: 65 | 66 | > MFA or Not MFA: Is it MFA when you answer a security question after entering your password? 67 | 68 | Building custom trainings can take a lot of time, but it also allows you to provide more information in areas where your organization is weaker, and be less specific in areas where your organization is stronger. To get started, take a look at our [Security Training Ops Guide](https://sudo.pagerduty.com/)—we have all of our public slides available for all the trainings on that page, as well as their Keynote files and PDF export. Our training materials are open source under the [Apache License](https://github.com/PagerDuty/security-training), so please feel free to use and repurpose to suit the needs of your organization. 69 | -------------------------------------------------------------------------------- /docs/index.md: -------------------------------------------------------------------------------- 1 | ![DevSecOps Guide Home Page](/assets/images/headers/home.png) 2 | 3 | ## Who is This For? 4 | 5 | This guide is written primarily for individual contributors who are not currently security engineers, but are interested in learning ways to improve how they implement security practices in their code and how they interact with their security teams and/or consultants. The focus of this guide is to define DevSecOps and dive into ways to support it within an organization. 6 | 7 | ## What is Covered? 8 | 9 | ### Introduction 10 | 11 | - [What is DevSecOps, its benefits, and how to implement](introduction/) 12 | - [Security Terminology](terminology/) 13 | 14 | ### Cultural Changes 15 | #### Building Empathy & Team Interactions 16 | - [Walk A Mile: Shadowing](culture/building_empathy/#walk-a-mile-shadowing) 17 | - [Full-Service Ownership](culture/building_empathy/#full-service-ownership) 18 | - [Security Champions Program](culture/building_empathy/#security-champions-program) 19 | - [Meet Needs to Gain Momentum](culture/building_empathy/#meet-needs-to-gain-momentum) 20 | - [Team Interactions](culture/team_interactions/) 21 | 22 | ### Implementation 23 | #### Shift Left 24 | - [Identify Your Needs With a Security Assessment](implement/shift_left/#identify-your-needs-with-a-security-assessment) 25 | - [Assessment Frameworks](implement/shift_left/#assessment-frameworks) 26 | 27 | #### Training and Education 28 | - [Threat Modeling Exercises](implement/training/#threat-modeling-exercises) 29 | - [Capture the Flag Games](implement/training/#capture-the-flag-games) 30 | - [Establish Trust: Don't Do Gotchas](implement/training/#establish-trust-dont-do-gotchas) 31 | - [Socially Engineer Security Trainings](implement/training/#socially-engineer-security-trainings) 32 | 33 | ### Additional Information 34 | - [Secure Software Development Life Cycle](secure_sdlc/) 35 | - [Resources and References](resources/) 36 | 37 | 38 | 39 | ## License 40 | 41 | This documentation is provided under the Apache License 2.0. In plain English, that means you can use and modify this documentation and use it both commercially and for private use. However, you must include any original copyright notices and the original LICENSE file. 42 | 43 | Whether you are a PagerDuty customer or not, we want you to have the ability to use this documentation internally at your own company. You can view the source code for all of [this documentation](https://github.com/PagerDuty/devsecops-docs) on our [GitHub account](https://github.com/PagerDuty/). Feel free to fork the repository and use it as a base for your own internal documentation. 44 | -------------------------------------------------------------------------------- /docs/introduction.md: -------------------------------------------------------------------------------- 1 | ![Introduction](/assets/images/headers/introduction.png) 2 | 3 | ## What is DevSecOps? 4 | 5 | Simply put, DevSecOps is parallel to the changes that happened to development and operations as part of the DevOps transformation. In other words, the goal of DevSecOps is to break down the security silo—similar to how DevOps breaks down the silos between development and operations. 6 | 7 | In a lot of organizations today, security is positioned at the “end of the line.” Products, features, and fixes are written, tested, built, tested again, and when they are ready for release, they are vaulted over the wall to security. At this point, any changes that security finds are expensive to make, largely due to all of the development time already invested. It’s also usually the case that the communications were not efficient while the issue was remedied. In this scenario, the security team needs to vault the situation(s) back over the wall to development and operations to resolve, and back and forth until whatever issue(s) are remedied and can then be released to production. 8 | 9 | At this juncture, DevSecOps and DevOps should feel very familiar. Just like DevOps, DevSecOps requires weaving together the seemingly disparate teams and workflows. Since there are security implications at every stage of the software development life cycle, or SDLC, (unlike DevOps, which was able to stitch two groups together), DevSecOps requires developer and operations to become more security aware. And in turn, security becomes more aware of the implications of releasing software in production. 10 | 11 | ## Benefits 12 | 13 | Implementing DevSecOps enables you to immediately see a reduction in security vulnerabilities found at the end of the SDLC as security is integrated more and earlier. Other improvements include: 14 | 15 | * Fewer security vulnerabilities that make it to production 16 | * Fewer security incidents 17 | * Less time resolving security incidents 18 | * Reduced human error as security checks and tests are included in build pipelines 19 | * Increased user trust 20 | * Builds empathy between teams and breaks down cross-team, adversarial relationships 21 | 22 | ## How to get there? 23 | 24 | There are two large pillars that support DevSecOps: 1) the cultural changes and 2) the supporting technical changes. The cultural changes that are covered in this guide are centered around improving cross-team communication, collaboration, awareness, and empathy. More specifically, there are activities that each of the development, operations, and security teams can do that will allow them to experience “a day in the life” and beyond for the other disciplines. 25 | 26 | The technical changes that support a DevSecOps culture involve integrating security in every aspect of the SDLC, a process called “shifting security left”. The purpose of this guide will not be prescriptive for how to shift left, but rather to provide the information necessary for development, operations, and security to meet their current challenges and build a path forward that best suits the current state and desired end state. 27 | 28 | -------------------------------------------------------------------------------- /docs/markdown.md: -------------------------------------------------------------------------------- 1 | ## A Sample Ops Guide Markdown Page 2 | 3 | ### Something About "Why This Guide, In Particular?" 4 | We wrote this guide because it was an _awesome_ request, and also because it met some business needs. 5 | 6 | ### So you don't like Markdown 7 | 8 | Writing in Markdown is hard. If you're developing on a Mac and would like to see it rendered, try using 9 | [Macdown](https://macdown.uranusjr.com/). This will allow you to see the live view of the Markdown. 10 | 11 | Note that this only applies to standard Markdown, not the customiziations for these guides like `tips`. 12 | 13 | You can test by opening this file with that editor / the Markdown editor of your choice. 14 | 15 | ### Some Markdown Basics 16 | 17 | - Here is a bulleted list 18 | - With another item 19 | 20 | And sometimes order matters 21 | 1. So this is first 22 | 1. And this is second 23 | 24 | ### Some Sample Customized Markdown 25 | 26 | Here's the syntax for customized Markdown that is used in the Guides. 27 | 28 | 29 | ## Always Include the License Statement 30 | ***However you ultimately build your index.md file, make sure it always has the following at the bottom.*** 31 | 32 | ## License 33 | This documentation is provided under the Apache License 2.0. In plain English, that means you can use and modify this documentation and use it both commercially and for private use. However, you must include any original copyright notices and the original LICENSE file. 34 | 35 | Whether you are a PagerDuty customer or not, we want you to have the ability to use this documentation internally at your own company. You can view the source code for all of [this documentation](https://github.com/PagerDuty/automated-remediation-docs) on our [GitHub account](https://github.com/PagerDuty). Feel free to fork the repository and use it as a base for your own internal documentation. 36 | -------------------------------------------------------------------------------- /docs/resources.md: -------------------------------------------------------------------------------- 1 | ![Attributions, References, and Resources](/assets/images/headers/resources.png) 2 | 3 | The goal of all of these exercises is to help development, operations, and security better understand how each group contributes to a secure SDLC. On the development and operations side, doing exercises like Threat Modeling and Capture the Flag as mentioned previously, help them develop a better understanding of how to weave security into their processes. Similarly on the security side, exercises like owning a service through production and shadowing helps them understand why development and operations structure their workflows the way they do. 4 | 5 | As a reminder, make sure you have a firm understanding of where your gaps are so that as you begin to shift left you are doing so in a way that meets existing needs. As you continue your journey in security, there are several common resources that are used in the industry and went into the creation of this guide. 6 | 7 | ## External contributors 8 | 9 | * Patrick Debois, Director of Market Strategy, Snyk ([Twitter](https://twitter.com/patrickdebois)) 10 | * Brad Lhotsky, System and Security Administrator, craigslist ([Twitter](https://twitter.com/reyjrar)) 11 | 12 | ## Resources to Keep Handy 13 | 14 | * Websites 15 | * [OWASP](https://owasp.org/) 16 | * [NIST](https://www.nist.gov/) 17 | * [CVE database](https://cve.mitre.org/) (Common Vulnerabilities and Exposures by Mitre) 18 | * [CWE database](https://cwe.mitre.org/) (Common Weakness Enumeration by Mitre) 19 | * [NVD](https://nvd.nist.gov/) (National Vulnerability Database by NIST) 20 | * Books 21 | * [Alice and Bob Learn Application Security](https://www.wiley.com/en-us/Alice+and+Bob+Learn+Application+Security-p-9781119687405) by Tanya Janca 22 | * [Defensive Security Handbook](https://www.oreilly.com/library/view/defensive-security-handbook/9781491960370/) by Lee Brotherston, Amanda Berlin 23 | * [Tribe of Hackers Blue Team: Tribal Knowledge from the Best in Defensive Cybersecurity](https://www.wiley.com/en-us/Tribe+of+Hackers+Blue+Team%3A+Tribal+Knowledge+from+the+Best+in+Defensive+Cybersecurity-p-9781119643425) by Marcus J. Carey, Jennifer Jin 24 | 25 | ## How to Contribute to this Guide 26 | 27 | Contributors are always welcome to help us keep the guide complete and correct. Also, in order to expand the content of the guide, topics related to the following have been slated to be added over time. If you would like to contribute to these topics, make suggestions, correct any errors, etc. please feel free to reach out by submitting a pull request or issue on GitHub (repository link [here](https://github.com/PagerDuty/devsecops-docs) as well as the upper left). You can also reach out to us on our [Community Forums](https://community.pagerduty.com/forum/). 28 | 29 | Some top level topics that we are looking at: 30 | 31 | * Compliance: Outlining what it is and isn’t and how it relates to DevSecOps 32 | * Organizational design: Within the DevSecOps context 33 | * Incentivization: How to align incentives between development, operations, and security so they are complementary and not oppositional 34 | * New Resources: Please feel free to submit common resources for people to grow their knowledge in security and DevSecOps. Intended audience is the same as the guide, technologists outside of security looking to be security aware. For these, we do not favor any particular vendor, rather we are looking for common introductory material (e.g. Alice and Bob) and/or frequently referenced material (e.g. OWASP). 35 | 36 | -------------------------------------------------------------------------------- /docs/secure_sdlc.md: -------------------------------------------------------------------------------- 1 | ![Secure Software Development Life Cycle](/assets/images/headers/secure_sdlc.png) 2 | 3 | To help you in your security journey, there are several tests and other actions that can be performed at different stages of the software lifecycle. For an idea of how and when certain tests and actions are performed, take a look at the following secure SDLC: 4 | 5 | ![Six Pillars DevSecOps Diagram](/assets/images/six-pillars-of-devsecops-secure-sdlc-diagram.png) 6 | Figure from [Six Pillars of DevSecOps: Automation](https://cloudsecurityalliance.org/artifacts/devsecops-automation/) by the Cloud Security Alliance 7 | 8 | Threat modeling and security assessments were covered in the [Shift Left](implement/shift_left/) section of this guide, but what about the rest? For the breakdown, you’ll see each action is preceded by a trigger. For example, the static testing is not done at any point in the secure coding phase, but specifically should be done whenever there are changes to the codebase. As for the actions themselves, here’s a quick overview separated by stage. (For tests that are repeated in more than one stage, they are listed under the first stage they appear.) 9 | 10 | ## Secure Coding 11 | 12 | * **Static Application Security Testing (SAST)** 13 | * SAST, also referred to as Static Code Analysis, does not require a compiled application to run - so it can, and should, be run early in the SDLC. The test reveals vulnerabilities in the code, specifically those in the OWASP Top 10 like SQL injection. 14 | * **Software Composition Analysis (SCA)** 15 | * A software composition analysis scans software, as well as its dependencies, and displays a list of known vulnerabilities as well as licenses and noting any deprecated dependencies. 16 | * **Secure Code Review** 17 | * “A secure code review is a specialized task involving manual and/or automated review of an application's source code in an attempt to identify security-related weaknesses (flaws) in the code. It does not attempt to identify every issue in the code, but instead looks to provide insight into what types of security-related problems exist and help the application developer understand what classes of issues are present.” ([Mitre](https://www.mitre.org/publications/systems-engineering-guide/enterprise-engineering/systems-engineering-for-mission-assurance/secure-code-review)) 18 | 19 | ## Continuous Build, Integration, and Testing 20 | 21 | * **Container and Image Scan** 22 | * Checks the build process of your containers and images for vulnerabilities. This should be done to establish trust with the base image or container, as well as any composites. 23 | * **Dynamic Application Security Testing (DAST)** 24 | * DAST is for compiled code / a running application without knowledge of the environment, simulating a hacker. Since the code is running for the test, this test is good for identifying issues with the runtime environment as well. Note that DASTs are only run on web applications and services. 25 | * **Fuzzing** 26 | * Testing with unexpected inputs. This can be something like testing if a non-date is entered in a date field, or even (trying to) drop a binary file in a text field. The goal is to capture these cases and ensure that the application does not crash and gives a usable error message. 27 | * **Interactive Application Security Testing (IAST)** 28 | * An IAST tests the running application for vulnerabilities during use, similar to a DAST. Unlike a DAST, an IAST can identify the line of code that is the source of a particular vulnerability. 29 | 30 | ## Continuous Delivery and Deployment 31 | 32 | * **Sign** 33 | * Verifies both the signature of the code and that the code has not been tampered with. This can be done for local and/or remote signatures and uses a cryptographic hash. 34 | * **Artifacts and Image Repository Scan** 35 | * An artifact scan scans all the artifacts that were created during development for vulnerabilities, and an image repository scan scans images when they are pushed to a repository. Any images that fail the scan are not uploaded. 36 | * **Systems, Containers, and Network Vulnerability Scan** 37 | * Scans for known vulnerabilities in the systems, containers, and networks. 38 | 39 | ## Runtime Defense and Monitoring 40 | 41 | * **Systems, Containers, and Network Vulnerability Monitoring** 42 | * Monitoring systems, containers, and networks for known vulnerabilities with observability tools. 43 | * **Runtime Application Self-Protection (RASP)** 44 | * Briefly, RASP works by adding sensors into the code so that execution points to watch for exploits happening in real time. 45 | * **Penetration Testing** 46 | * Penetration testing, frequently referred to as pen testing, is a simulated attack to test for vulnerabilities. This type of testing can be done either [black box or white box](terminology/#white-box-vs-black-box) and can be done on the applications, services, systems, networks, etc. 47 | -------------------------------------------------------------------------------- /docs/terminology.md: -------------------------------------------------------------------------------- 1 | ![Terminology](/assets/images/headers/terminology.png) 2 | 3 | As you start your DevSecOps journey, it’s important to use common language and share common concepts with your security team. To help you get started, here are some industry terms and concepts, some of which you’ll need in the guide directly, but all of which you’ll need as you broaden your knowledge. 4 | 5 | ## OWASP and NIST 6 | 7 | 8 | **OWASP** (Open Web Application Security Project) and **NIST** (National Institute for Standards and Technology, US Based) are two heavily used resources for security tools, resources, and research. 9 | 10 | ## Security posture 11 | 12 | An organization's **security posture** is the overall security status across your technical organization, including software, networking, data, vendor risk, dependency security, vulnerability management, and more. Knowing your security posture is vital to understanding how at risk you are to various types of security threats, such as data breaches, and will allow you to know what to remediate and with what urgency. 13 | 14 | ## Attack Vector and Attack Surface 15 | 16 | An **attack vector** is any method that an intruder can use to gain access to your systems and information. For example, if/when a key is committed to GitHub, if someone else used that key to access the service, that exposed credential would be considered an attack vector. The **attack surface** is all of the attack vectors. For example, the exposed credential, any unencrypted data, and so forth, would be your organization’s attack surface. 17 | 18 | ## Perimeter 19 | 20 | A **perimeter** is the barrier that prevents access, similar to what you would see with physical security where natural or built walls, etc., prevent access. In this case, the walls would be what separates public and private networks, firewalls, access controls, and so forth. 21 | 22 | ## Security Breach 23 | 24 | A **security breach** is whenever someone gains unauthorized access of any kind, including network or application access. 25 | 26 | ## Data Breach 27 | 28 | A **data breach** is any release of confidential information to public sources. Common examples are credit card numbers, government ID numbers, addresses, and other identifying information. The release may be unintentional or intentional. Note the difference between a security breach and a data breach: the security breach is the gaining of access (“breaking in”) and the data breach is taking information out from where it was secured (the “theft”, also referred to as **exfiltration**). 29 | 30 | ## Exploit 31 | 32 | An **exploit** is code that takes advantage of a vulnerability. 33 | 34 | ## Trust 35 | 36 | Establishing **trust** is the verification that a resource or user is who is claimed. An example of a trusted resource might be verifying that the application patch or update is from an intended source, or that the user who is attempting to access data is associated with the intended person or entity. 37 | 38 | ## Zero Trust 39 | 40 | Although there are other models, in recent years **zero trust** is a model for security that has become an industry standard. In fact, we practice it here at PagerDuty. Concisely, zero trust is a model for continuous authorization. It does not assume that, because a user is able to access certain data or devices, that that user should be there, so users are always prompted for their credentials for access. As an example, in a zero trust environment, the network a user is coming from does not grant assumed access, e.g. if the user is connecting via a company VPN—all access requests still need to be authenticated. 41 | 42 | ## Threat Actor 43 | 44 | **Threat actors** are the types of individuals or groups that you anticipate are most likely to try to breach your security measures. For example, you might find that you are most likely to be hit by scripts that are not targeting you directly, but instead are targeting a service that you are using or region you are in. 45 | 46 | ## Risk Management 47 | 48 | **Risk management** is the ongoing process of identifying what security risks you have in your organization and how to prevent, mitigate, and resolve them. It starts by identifying the risk associated with various assets, such as personal information, and determining both how likely they are to be the focus of an attack and what the impact of an attack would be if it were to happen. 49 | 50 | ## White Hat vs Black Hat 51 | 52 | Usually in reference to hacking, a **white hat** hacker is a person who hacks or tests the security of a system with the owner’s permission and informs the owner of all vulnerabilities found. Conversely, a **black hat** hacker is someone who tests the security of a system, usually with the intent to breach it, without the owner’s permission and does not inform them of vulnerabilities found. As an example, a white hat hacker or group might be a security consultancy brought in to run a pen test, whereas a black hat hacker might be trying to steal customer credit card information. As a quick note, you may also come across the term **grey hat**, which is someone who breaches security but without the malicious intent of a black hat attacker. 53 | 54 | ## White Box vs Black Box 55 | 56 | **Black box** is when a system is known only by its behavior, basically its inputs and outputs, without knowing anything about how it is built (e.g. AWS vs GCP). On the other hand, **white box** is when you know the architecture of a system. These terms are usually used in reference to testing, where black box testing is when you test an unknown system and white box testing is testing a known system. 57 | 58 | ## Red Team, Blue Team, Purple Team 59 | 60 | Similar to white hat hackers, **red teams** specialize in breaching security, with permission. Red team exercises are usually done by security teams to simulate what an external attacker is likely to do in order to obtain whatever they are targeting, e.g. secure data. On the opposite side is the **blue team**, which specializes in defensive security. Blue team exercises can be the defensive response to red team exercises, but they can also be other things like audits. When red teams and blue teams coordinate, it’s called **purple teaming**. 61 | -------------------------------------------------------------------------------- /mkdocs.yml: -------------------------------------------------------------------------------- 1 | # Project Information 2 | site_name: PagerDuty DevSecOps Documentation 3 | site_description: This guide is an introduction to DevSecOps, the cultural practice of integrating the security team into the process flow of development and operations. 4 | site_author: PagerDuty, Inc. 5 | site_url: https://devsecops.pagerduty.com/ 6 | 7 | # Repository 8 | repo_url: https://github.com/PagerDuty/devsecops-docs 9 | 10 | # Copyright 11 | copyright: 'Copyright © PagerDuty, Inc.' 12 | 13 | # Theme 14 | theme: 15 | name: pagerduty 16 | title: 'DevSecOps' 17 | 18 | # Contents 19 | nav: 20 | - Home: 'index.md' 21 | - Introduction: 'introduction.md' 22 | - Security Terminology: 'terminology.md' 23 | - Cultural Changes: 24 | - Building Empathy: 'culture/building_empathy.md' 25 | - Team Interactions: 'culture/team_interactions.md' 26 | - Implementation: 27 | - Shift Security Left: 'implement/shift_left.md' 28 | - Training and Education: 'implement/training.md' 29 | - Additional Information: 30 | - Secure SDLC: 'secure_sdlc.md' 31 | - Resources and References: 'resources.md' 32 | 33 | # Analytics 34 | google_analytics: ['UA-8759953-1', 'auto'] 35 | 36 | # Extensions 37 | markdown_extensions: 38 | - toc: 39 | permalink: '#' 40 | - sane_lists: 41 | - admonition: 42 | - meta: 43 | - pymdownx.details: 44 | - pymdownx.extra: 45 | - pymdownx.mark: 46 | - pymdownx.tilde: 47 | - pymdownx.highlight: 48 | - pymdownx.superfences: 49 | - pymdownx.tabbed: 50 | 51 | # Development URL, bind to local only. 52 | dev_addr: '127.0.0.1:8000' 53 | 54 | -------------------------------------------------------------------------------- /netlify.toml: -------------------------------------------------------------------------------- 1 | [[headers]] 2 | for = "/*" 3 | [headers.values] 4 | Strict-Transport-Security = "max-age=31536000 ; includeSubDomains" 5 | X-Content-Type-Options = "nosniff" 6 | X-Frame-Options = "DENY" 7 | X-XSS-Protection = "1; mode=block" 8 | Referrer-Policy = "same-origin" 9 | Feature-Policy = "accelerometer 'none'; camera 'none'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; payment 'none'; usb 'none'" 10 | Content-Security-Policy-Report-Only = "default-src 'none'; script-src 'self' ssl.google-analytics.com www.google-analytics.com 'sha256-AzwHtScSzFOoXIoLRz4+vK2rDADGdNC3AXQG5FjKK68=' 'sha256-8IZh+gkrYCTCvcu/zawPN9Vj4RLghgOT4F5rTZXvdkQ='; object-src 'self'; style-src 'self'; img-src 'self' data: ssl.google-analytics.com www.google-analytics.com; media-src 'none'; frame-src www.youtube.com www.youtube-nocookie.com; font-src 'self'; connect-src 'self' ssl.google-analytics.com www.google-analytics.com; base-uri 'none'; form-action 'self'; frame-ancestors 'none'" 11 | 12 | -------------------------------------------------------------------------------- /requirements.txt: -------------------------------------------------------------------------------- 1 | mkdocs 2 | pymdown-extensions 3 | pygments 4 | git+https://github.com/pagerduty/mkdocs-theme-pagerduty.git@master 5 | -------------------------------------------------------------------------------- /runtime.txt: -------------------------------------------------------------------------------- 1 | 3.8 2 | -------------------------------------------------------------------------------- /screenshot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PagerDuty/devsecops-docs/8f3941c9cddd219d1fad11552f6852da010613d2/screenshot.png --------------------------------------------------------------------------------