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.
What can we do during requirement management to contribute to information secure applications?
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.
How do you stay up-to-date on IT security?
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.
What is security in the development process?
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.
How do you manage security in both the infrastructure and at the application level when the systems are somewhat older in version?
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.
Is there a Best Practice for building a solid process around continuous internal controls?
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.
How do you develop secure applications in the Cloud?
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.
Is there a good checklist that you can recommend highlighting security issues in requirement management?
Yes, OWASP ASVS
Is there a way to verify that you have a safe product?
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.
What is Privacy by Design?
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.
Could an automated test be an option since human skills are in short supply? Or should you have the combo? Can you recommend any tests?
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.
The persons behind the answers
Jon Jezierski
Jon is a passionate IT security specialist with more than 14 years of experience across a wide range of disciplines. Over the years, he has worked in most sectors and performed over 700 technical analyzes in 12 different countries.
Patrik Jezierski
Patrik has worked within IT security since 2010. During these years, he has mainly worked as a penetration tester, but at his long-term assignments he has had several different roles within IT, which has resulted in his wide knowledge in the industry.
Mattias Döj
Since 2016, Mattias has worked with a large number of complex systems. Initially as a developer and test automatizer, but for the majority of the time he has worked as an IT security consultant at a variety of global companies.
Webinar On-Demand
How to think and work with
application security
Most of us understand that security is important but don’t really know how and where to start. In this webinar, we will talk about application security with a focus on bringing security into the development process, the common attacks, etc.
Career path
We are looking for more IT Security Consultant
We are a team who are all interested in penetration testing, development, love to take on new challenges and have a good sense of humor and laughter. Whether you’re a senior or junior doesn’t matter to us, we in the team will help and lift each other to be the best we can be, as soon as possible.
