What brought me to this?
So last year I was talking to a recent college graduate.
(I offer free discussion sessions regarding career, security or just normal chit-chats here )
He was excited at landing his first “SOC” analyst job. He wanted to discuss how he should go about learning more technologies. And our conversation eventually led to “DevSecOps” and how he should pick up some “devsecops” skill. That’s when it hit me. Everybody defines “DevSecOps” differently.
Don’t believe me, just Google “What is DevSecOps?” and let me know if I am wrong.
What is the issue?
To start off I think the basic issue people fail to understand what is “DevSecOps” and it’s difference from “Security Engineering”
For example there are books that have title “Securing DevOps” but goes into Compliance from the first chapter.
Then there are “Udemy” and “Youtube” courses that goes into Securing Kubernetes Cluster or Securing your AWS Environment in the name of “DevSecOps”.
Then there are further examples of setting up Endpoint Detection And Response systems as part of “DevSecOps”.
But aren’t they necessary as well for Security?
Don’t get me wrong I am not saying all the above mentioned are not essential but if you are using a term it is important to define it correctly.
So let’s understand what is DevOps. Other than the culture aspect of DevOps at it’s core DevOps is the practice of “Code”-ifying your operations work, so that your infrastructure can become “Deploy”-able with the same reliability each time.
Now Security in an organization is securing your infrastructure. So if your infrastructure is “code”-ed thanks to “DevOps”, “DevSecOps” is the practice of “Securing” this code.
I am not saying I know it all. If anybody has criticism, please let me know 😄
So if I want to learn “DevSecOps” what should I focus on?
Learning how to automate should be your first goal
Easier said than done. This step focuses on learning a scripting language at the very least. If you are going to secure “code”, you should learn how “coding” works. The best way to learn this is to pick up a scripting language, any scripting language. Then learn how to automate small daily stuff with it. There are millions of youtube videos on “Writing Code to automate” to go through.
Secure Coding Practices
Now you need to focus on securing “coding” practices. That means the ability to understand how to handle passwords, secrets on the fly and to not intentionally introduce vulnerabilities in your code. Filtering user inputs, making sure there are no SQL injection vulnerabilities etc. An example could be let’s say, if your application or code needs to authenticate itself to let’s say a Database, then how you handle that without writing the password in your code.
Checking Dependencies of your code base
Now let’s say your entire infrastructure is “code”-ed. Or at least part of it is. Now if you have learnt the basics of “coding”, from the point I made above, you will know that sometimes some code depend on other 3rd party codes or code modules. So even if your organization’s “code” is secure, the other party’s code might not be. To learn how you safeguard this you should learn how to:
- Setup your own CI/CD Pipelines
- Setting up Code Versioning and
- Checking your code and handling code dependencies.
Giving your developers the ability to fix security holes themselves
This basically revolves around introducing
- Static Application Security Testing (SAST) Tool for your code base
- Container audits
- IAAC Scanning Tools
The above are scanning tools meant to scan either your code, or your container configurations or your IAAC configurations and let your engineers or developers know of potential vulnerabilties. This is why another aspect of DevSecOps is to learn how to audit all your different types of code bases with the help of the tools above.
Threat model, threat model, threat model
The final step is to figure out potential attack surface or vulnerable areas of your code/application/infrastructure before it goes live. You make all new projects go through design review or threat modelling before a single line of code is written. The idea is 2 fold here:
- If there is a potential attack surface area that you can avoid take the decision here in the design phase itself before a single line of code is written or a single piece of infrastructure is deployed. An example could be using “https” rather than “http”.
- If there is a potential attack surface area that you cannot avoid you can get your Security Tools ready to fend off attacks for that surface area. An example could be updating your firewall rules to make sure that there is rate limiting turned on for failed login attempts for your website.
Learning these tools that examine and identify all potential points of attacks that hackers could exploit and how they could do so, thus is an important part of “DevSecOps”
Conclusion
Check out my other blog posts here ✏️
If you want to chit-chat, discuss security topics, learn how to get into security or just plain hang out feel free to reach out via my socials or setup a mentoring call:
📞
