Software Security Trends
When developers use open source libraries, they include them in their products and then they don’t really think about the vulnerabilities that are coming through that open source it becomes a problem for the entire ecosystem. We saw that with Heartbleed, everyone scrambling around trying to patch. Their usage of the SSL library if you’re using open source, you really have to think about it differently. You have to think about it as you’re managing something a supplier is delivering to you, but you have to think about, what’s the Bill of materials of my software, What did the supplier drop off to me? And then I have to make sure that I’m keeping track of vulnerabilities as they come forward in the future and update that. So it’s kind of like a car manufacturers that you know keeping track of all the parts they use in case there’s a defect that say air bags and you need to do a replace.
It’s interesting because modern secure software development has changed because development practices have changed. Modern software development is much more iterative now and much more agile where things aren’t planned out in advance and you have people writing software where they are going from. New feature idea to delivering that software in in maybe a week or two or even in days, and so modern Software security has had to adapt to that. What you need to do is you need to do things in small chunks and iterative way so that, your threat modeling just that one new feature at a time, sort of on demand. Or are you doing manual penetration testing On just one feature at a time and your automation has to run at the speed of your of your development pipeline so that if your development pipeline, you know building and running your automated tests takes a few minutes, your security testing has to fit into that few minutes too. So this is where we’re seeing automated tests get faster and faster, but also operate on smaller and smaller chunks and shifted further and further left. So you’re not you’re you’re working on the little pieces of the application and it makes it much quicker to get to discovering that vulnerability. So let’s talk about shifting left. What does shifting left mean and how do you do it? Shifting left means that you’re really becoming part of the development process. And not even just becoming part of the process before we deploy the software, let’s run all our security all at once, right before we deploy it. The problem with both of those is you’re about ready to deploy your software when you get this big list of things to fix. So obviously that’s going to slow things down. So shifting left is trying to discover the vulnerabilities as close to when those vulnerabilities are created as possible. So you would want to be doing automated testing, you know on a feature branch as a developer or some developers are working on a feature before it’s in that mainline branch when they’re designing. Hey, we are we done? Here are we done with this feature? Are we going to commit this code? Shifting left would be like left to our security testing there it as in part of the pipeline when I’m doing my unit testing. You can even shift further left. And scan code in the IDE. As a developer is scanning, there are some limitations that you don’t have the full context of the application because you might just be looking at. You know, one method of code, one class of code. But if you can find a certain percentage of vulnerabilities there, that’s that. That’s great. The other thing is third party Code when you bring up open source library into your application you wanna understand if that version has vulnerabilities right? Then when you first start using it or when you’re building in the pipeline, you don’t wanna find this after the fact, so lots of different techniques of testing software can be shifted left. And even penetration testing can be shifted left. So how do you actually incorporate security into the process? What tools do you use? If you’re a company is trying to transition to this process, which should they be thinking about? Is there any foundational elements, yeah. So foundational elements for tools would be things like static analysis. Which you know it’s basically grew out of code review.So you can actually inspect all the code just like you would inspect code by doing a code review. Except you’re doing it extremely fast and you can look for a huge amount of different coding patterns.
If control flow and data flow and usage of risky functions that will highlight something that’s exploitable. Also, Software composition analysis which tells you what open source you’re using, but there’s a real benefit to doing runtime testing. Which actually models how the code is running in a particular environment, so tools like dynamic application security testing which really focus on exercising a web interface or an API interface, a Restful API. There’s interactive application security testing which inspects code as it’s running. It’s being driven by unit tests or other kind of testing and those types of tests can be built into the pipeline, also tell you things that you might not be able to see because there they can see how the code is interacting with its environment. So other microservices, other APIs that are outside of your system, the actual you know container stack, it might be running it that those types of testing can see more.
Another interesting question is how should companies assign ownership of secure code across the software development lifecycle? This is one that I think makes a huge difference, and it’s assigning the ownership of the security of the code to the people who are writing the code. When you have a finding whether that was found by an external pen tester. Some static analysis tool. It should get routed to the people who own that piece of code. Ideally, they’re the ones doing the testing right? They’re running the testing and so it’s close to the time when that code was produced. You know, I see all the time where you wait and have pile of tech debt and security debt till the end of a many month project and you find all these vulnerabilities and then you go to fix them and the people who wrote the code aren’t even on the team anymore or I’ve seen places where they don’t want to take up the time for the developers that are their prized developers who wrote the code and they outsource the fixing. The problem I see with that is it takes longer to fix. It might be cheaper actually, but the real downfall of that kind of model is the people who created the vulnerabilities in the first place don’t get to learn from that Feedback loop. How can somebody present maybe this security organization work with that group to raise the level of priority and get that part of their remit. The way I’ve seen it work well and this is something we actually do it fair is something that I’ve seen work that team helps each individual scrum team get up to speed, and ideally educates the team with training and even goes above and beyond that and create a security champion within that team to try to scale out the expertise and they can help out. When this vulnerability is found they can pair up with a developer that’s fixing it. If you have incident response capabilities in the Hunt team, you start doing incident response that is, start thinking of ways that you can block the attacker so they don’t cause anymore damage and that you can eradicate them quickly.
Tools that can be recommended from a free tool perspective let’s focus on two types of tools. One is sort of a framework environment that you could do threat hunting in and the other is individual piece part tools, and you kind of want to have both and they also work together. So from this sort of framework threat hunting environment, there’s some great tools that are available. There is a tool called Zeek it is a great environment for gathering data from a network, including things like packet captures, including things like logs, including things like issues discovered on end systems and then doing various kinds of queries and analysis of it. Another great one is an entire Linux distribution called security Onion, another one is Deep Blue CLI (Command line interface). It is a series of PowerShell scripts that you can feed Windows event logs to and it applies various heuristics to go through the Windows event logs, and it’s really easy to use. You simply run Deep Blue CLI and it tells where the file is with your event logs, and it kind of chunks through the whole file saying I see some evidence here that looks like an attacker did lateral movement from the system to that system. There’s another free standalone tool called RITA, it’s focus is on network activity that might be nefarious. Another tool that’s really quite nice, especially working in a multi operating system environment, is tool called OS Query. Deep Blue CLI focuses on Windows event logs, If you look at RITA, it focuses on network activity, but OS query can pull information not only from Windows machines, but also things like Mac OS systems and other operating systems, which is kind of cool.
Microsoft System journals has Sysmon,It is also is a miracle. It gets you very detailed insight into what’s happening on a Windows machine so that you can look at all the processes, the process hierarchies, like what is the parent process of this process, was the parent process of that, what DLLS are they loading, what interactions are they having with the registry. It is an incredible tool for doing detailed analysis, so I recommend it for any threat hunter Or would the threat Hunter understands Sysmon start looking at that, It’s freely available from Microsoft. There is also some really great stuff from a threat hunting perspective in various cloud services. For example, in Microsoft Azure, there’s a set of features bundled together called Sentinel. And if you go into Azure Sentinel, there’s a specific page on hunting with built-in queries that you can use to find anomalous things, Azure Sentinel is a SIEM (Security Information and Event Management) and Security Orchestration and Automated Response (SOAR) system in Microsoft’s public cloud platform. It can provide a single solution for alert detection, threat visibility, proactive hunting, and threat response. OWASP has free tool named as Dependency checker that works for Java and other Object Oriented programing languages. Another big trend is this trend toward purple team, it used to be red would do their thing, and then if you detected it, that’s fine. If you didn’t have that or blue would do their thing, maybe even with threat hunting, but without integration with red and plus blue working together, I think that is a really huge thing that’s driving this forward.