In this post we’re addressing some of the most common questions we get about IT security. From understanding the importance of incorporating security measures during requirement management to staying up-to-date on the latest security trends. We’ll also explore the critical role security plays in the development process and offer insights into securing older systems and implementing continuous internal controls.
The OWASP top 10 is great to follow, it’s a list of the most common vulnerabilities in web applications. OWASP stands for Open Web Application Security and is an organization that works with security in software applications.
A few years ago OWASP ASVS (Application Security Verification Standard) was published, a great compendium to look at to catch security issues in requirements management. It can be used as a requirement statement for applications. ASVS is like a checklist on three different levels, start with level one and compare with what you have in place and what needs to be applied and continue with the next level. All applications must be able to pass level one. If you want to add security to your requirements, I would start with this. One tip is to start low and increase gradually, many companies make the mistake of applying too many things at once that the organization ultimately cannot handle.
We follow a lot of security people on Twitter, where we get good updates if something has happened or if a new tool has been released. We also follow blogs about security, for instance Daniel Miessler, Podcast, darknet diaries. Other than that, we look for tools, code snippets or scripts that people have released or are releasing and find out what they are trying to do.
When it comes to vulnerabilities, we don’t sit every day and keep an eye on whether a new vulnerability is released for a specific product. It’s when we have assignments that includes an application with a certain form of application stack, we look at what vulnerabilities exist right now. Otherwise, Linkedin is a good source for keeping up to date with new vulnerability releases.
Before Covid, big security events were organized in Vegas every summer, Black Hat, Def Con and BSides. A great place to network and listen to interesting sessions.
If we look at it from a penetration test perspective and based on our assignments, we have noticed that security enter development projects extremely late. Many times, as late as when the product is about to be released into production because the company realizes that they need to do a security test. And in the worst case we find lots of vulnerabilities that needs to be fixed. Which leads to a delay in the project and increased costs.
We would like to see companies working with security earlier in the development phase. You usually talk about Shift Left Testing when it comes to security, i.e., that we don’t apply security as an add-on feature at the end, but instead includes it from the beginning. Security should be included in the requirements.
By building security around the system, such as compensating controls all around with layer seven firewalls, deep packet inspection and by looking at the application layer. Also consider whether you should have Intrusion Detection System (IDS) and/or Intrusion Prevention System (IPS). These are some options for securing your slightly older systems.
Work with the 20 CIS controls. Which controls are in place in the company today?
When we talk about controls, it’s everything from:
– Do you have an anti-virus system?
– Do you keep track of your assets in the company?
– Do you have an overview of your applications in the company?
– Do you do penetration tests regularly?
– Do you have knowledge about administrative privileges?
– Are you using secure email solution?
It’s quite broad but a very good thing to follow if you want to start getting control, structure and some follow up to look at. As with anything else, don’t tackle everything at once, start small and take your time. Security is not something you do in a month, it is a long process. Large companies work and struggle continuously with the CIS controls, it is a big thing to implement if you want to comply with all 20.
If you separate the infrastructure and the application and start with the application part, we don’t see a big difference in the approach and what it should be able to handle. The infrastructure on the other hand, like Key Management and Secrets is different compared to pulling it on-prem in a data center. You have a lot of security in the Cloud directly, things that you may not have in your own data center, such as traceability to accesses. But for it to work as intended, it is necessary to configure it and configure it correctly. Cloud is not secure by default, and it‘s the user who must configure and activate these features before it’s live on the Internet.
Yes, OWASP ASVS
Yes, the Shift Left methodology. Start with security at the very beginning of development and test the product early. Other ways to verify that you have a secure product are penetration testing, SAST scanning (static analysis) and dynamic analysis in the form of web application scanning. These allow you to keep track of your application in the long run.
You can also make use of Threat modeling. Take your application, your developers and stand in front of a whiteboard and draw the application. You can break it down into smaller components or draw it more basic. Look at data flows, how and where they come in and out, what functions are available and start listing different possible attack modes and possible vulnerabilities. Then try to build and implement security into it.
Privacy by design is a nicer word meaning you should think about security at an early stage having security already in your requirements.
Threat modeling, as described above, early in development is a very good start. Look at what personal data you have and try to follow legal guidelines, GDPR applies to personal data and PCI DSS is a well-developed legal document for how to handle credit card data. When it comes to confidential information, you can check which legal frameworks you have to consider. After that, it is important to bring in the security processes, such as security requirements, threat modeling, code review, DAST tools, penetration tests and infrastructure tests in terms of automation tools.
Our recommendation is to automate more where it is possible to automate. We think you can do all checks that can be automated in, for example, ASVS or in a CICD process. Use automated tools, use DAST tools, code review tools or similar.
Our expertise is needed for the more complex questions and when the more complex tests are to be done. Often when we’re about to perform penetration tests companies haven’t done either code reviews or run DAST tools. Which means that we need to identify all types of vulnerabilities, which is a lot. The very best cases are when we get a report from a vulnerability scanning tool and when we look at the infrastructure and it turns out that code review and DAST tools has been run. Our work can be focused on all the other things that tools can’t do when it comes to pure logic. Such as logic management in an application, pure business logic and similar. Automated tools are not particularly good at identifying these, because they have no concept of how the application itself should actually work. Automate as much as possible and use our expertise for the things the tools can’t handle.
Tests we recommend:
OWASP ASVS, Level One is written so that you can pretty much automate completely. Another is the OWASP Testing Guide, a very good guide on types of problems and how to identify the vulnerability.
When it comes to tools, it depends on the company. No tool fits everyone.