Internal Security Audit Checklist for Increasing Product Quality

While many software development companies can develop a ready-to-use solution based on your request, not all of them can ensure robust security and therefore high product quality.

In reality, far fewer companies can provide you with a full-cycle service from creating a specification to providing support to end users while ensuring the quality and security of the final product.

Product security is especially relevant, as the number of data leaks has significantly increased over the past few years. According to a report by Risk Based Security, there were 5,183 breaches reported in the first nine months of 2019, which is up 33% compared to the same period in 2018.

In this article, we discuss the secure software development lifecycle, compare three ways of implementing security testing into your SDLC, and provide an example of an internal security audit checklist. This article will be useful for everyone who’s interested in ensuring robust security for an IT project.

Shifting to a secure SDLC

What is the best time to involve a security specialist to secure your product?

Though the most common practice is still to hire a team of penetration testers just before a major release, doing so results in a high cost of fixing errors. The reason is that some critical vulnerabilities can only be eliminated by redesigning an application’s architecture. Thus, the development team has to go back a few iterations, risking the delivery date.

In contrast, your project will be in a more beneficial position if you start auditing your product’s security before and during the development lifecycle. In this case, fewer issues will arise and they’ll be less expensive to fix.

The diagram below shows that fixing bugs and errors detected at the production/post-release stage costs six times more than fixing issues found at the coding stage. The data used for creating this diagram comes from a NIST report titled “The Economic Impacts of Inadequate Infrastructure for Software Testing.” [PDF]

So how can you reduce the cost of fixing security issues without significantly increasing your development budget?

Conducting penetration testing of the finished product is less effective than implementing security measures right from the start. You need to organize processes in a way that raises product security risks at all stages, from drafting specifications to setting up the environment and pentesting the finished product.

The practice of ensuring proper security during the software development life cycle (SDLC) is called securing the SDLC [PDF] and requires performing security-related activities during each development stage.

Although there are lots of approaches to SDLC implementation, like Agile development and the waterfall model, the SDLC isn’t standardized and can vary across organizations. A typical SDLC model includes the following five steps:

1. Requirements
2. Design
3. Development
4. Testing
5. Deployment

The main idea behind the secure SDLC approach is to implement security-related tasks such as safe coding training, threat modeling, and static vulnerability analysis into the product development life cycle.

This SDLC approach doesn’t allow you to move to the next stage until the developed functionality complies with all security requirements. Thus, you can eliminate the majority of issues right off the bat.

Three ways to implement security testing in your SDLC

Auditing product security at every stage of development is a sure way to build a robust solution. However, it may seem expensive and time-consuming.

In fact, security audits can be cost- and time-effective when thoroughly planned and timely performed. These audits allow you to detect defects before they lead to severe issues and require additional resources to fix. Having a tried-and-true checklist simplifies and accelerates the process.

The price of security testing services, the level of control, and the time required to fix errors will differ depending on the measures chosen to ensure product security.

There are three ways you can implement security testing services in your SDLC:

Let’s compare these three options and explore their key pros and cons.

Hiring an outsourced penetration tester for a security audit

Businesses often hire an outsourced pentester to test the final product and get an unbiased evaluation of its security. This option is popular among startups that want to check how secure their MVP is but don’t have their own security specialists.

The overall cost of this option isn’t that easy to calculate because apart from paying for an outsourced pentester, a company also spends its own internal resources. Team members have to spend time putting the pentester into the picture, providing consultations when needed, analyzing the final report, and drawing conclusions from it. On the other hand, the team doesn’t spend time on activities like instruction in secure coding and creating further strategies for improving the product.

The later a defect is detected, the more time and effort will be spent fixing it, especially if there’s a need to change the core functionality.

The time required to conduct an internal security audit depends on the project’s size and complexity, but it usually takes one to two weeks.

Also, a report from an outsourced pentester includes only information about current issues, and there’s no guarantee that new problems won’t arise after fixing the current bugs.

Involving a security consultant during the project planning stage

Another option for taking care of product security is to consult a security specialist when creating a list of product requirements. A security consultant can help you find drawbacks in the product specification and prepare a list of recommendations for addressing them. A good baseline here is the OWASP Application Security Verification Standard for web projects and the Mobile Application Security Verification Standard for mobile projects.

The idea of involving a security consultant during the planning stage is to eliminate the most common mistakes and risks before starting development. This option is often used by teams that have little or no relevant expertise and require consultations about secure coding and penetration testing.

If your company already has someone who can serve as a security consultant, the cost of such services is usually quite low. Involving an external specialist can be a little more expensive. In both scenarios, the project team will be involved in discussions with a security consultant about the product under development.

When addressing security issues during the planning stage, the cost of fixes is essentially zero, as nothing has been created yet. However, this approach doesn’t provide strong preventive measures. And since there’s no strategy on how to improve product security and quality in the future, security consultations will be needed each time something is changed in the software specification.

Implementing a secure SDLC approach

The most comprehensive and beneficial approach to ensuring a product’s security and quality is to build a secure SDLC. In this case, you assess the security not only of the final product but of all project processes. The best option for understanding your current status and creating a roadmap is to follow the OWASP Software Assurance Maturity Model [PDF].

Following this model, a team of experts involved in the project focuses on sharing helpful knowledge and skills with the project team. This could be in the form of a lecture or a workshop about secure coding or requirements evaluation. The goal is to provide development teams with knowledge that allows them to avoid future mistakes.

Apart from sharing knowledge with the development team, security specialists can help with conducting an internal security audit and arranging periodic reviews. Thus, you can make sure processes remain secure and that you can detect new issues early.

On the one hand, implementing a secure SDLC can be expensive compared to other options. But on the other hand, your development team will get the skills and knowledge necessary for building a robust, secure product. Not to mention that they’ll surely use these valuable new skills on other projects. Big companies like Apriorit regularly invest in employee training and education. Thus, our workers start new projects knowing the latest best practices and already familiar with our tools, recommendations, and processes.

Thanks to an initial audit, workshops, and periodic reviews, developers make fewer mistakes. Thus, the company saves resources on bug fixes and pentesting services and saves time on testing.

As you can see, each of these approaches has its upsides and downsides. At Apriorit, we apply all three approaches mentioned above to develop secure products for our customers and ensure product quality.

Now, let’s learn what an internal security audit is and how it can ensure robust product security. We’ll also offer an example of an internal security audit checklist.

Internal security audits for development projects

Apriorit project teams aim to ensure robust security for all our client’s projects. We make the quality of the final product our top priority and take every project as a mission.

Our internal team of pentesters and security consultants choose relevant security testing methodology and assist our developers in running security assessments and building secure solutions.

At the same time, we understand that we need a mature software development process with a list of default security controls that can be applied to all kinds of projects, from simple applications to custom solutions.

Each project should be monitored, so we’ve created an internal security audit checklist that focuses on processes instead of technical details. It’s also important that such an assessment doesn’t take too long to carry out.

Let’s explore the items on our assessment checklist:

Access permissions

First, you need to make sure credentials concerning the project aren’t stored publically and that only approved team members have access to them. Therefore, you should check the following:

• Data availability

No confidential data is publically available in collaboration tools used for the project: wiki, Confluence, etc.

• Access to confidential data

Only approved project members have access to pages with confidential data within the project’s collaboration tool.

• Access to critical resources

Only approved project members have access to the project’s source code management (SCM) system, FTP, SonarQube, build system, test documentation, and project belongings.

Project belongings

All IT projects require hardware and various devices for both product development and testing: PCs, smartphones, tablets, sometimes even musical equipment. You need to check that all devices and product licenses are included in the project belongings list. Make sure that:

• There’s a list of all project belongings

Make sure that such a list exists and includes all devices and product licenses used.

• The list is updated and contains accurate information

New devices should be immediately added to the list of project belongings. Such lists become useless if team members don’t update them regularly.

• Information about the current holder of each item is present

The list of project belongings has to contain information about the current holder of each device so you can find a device quickly.

• Project devices with confidential data are marked as not available for sharing with other projects

Devices provided by customers should be marked as prohibited for use on other projects. A company’s own devices, such as mobile phones and tablets, can be used across projects.

• Project belongings are stored in a safe

All customer devices are stored in a safe and only approved members of the project team have access to it.

Environment

By environment, we mean various elements of cloud infrastructure and hosts used within the project. Each team must have a specialist responsible for setting up the environment. Everything that is created, tested, and deleted from the server has to be documented.

A poorly managed IT environment can lead to serious issues, such as data leaks caused by an unnecessary internet connection.

You can prevent such problems from happening by making sure that:

• There is a specialist responsible for environment management

Each project should have an authorized person responsible for setting up the entire project environment.

• All environments are identified and documented

All project-related environments like build servers, build agents, hypervisors, cloud storage services, Docker containers, Kubernetes clusters, etc. should be documented. Information about required open ports and services has to be documented for each item.

• All environments apply the latest patches and security updates

All servers must apply the latest patches and security updates. Any exceptions should be discussed with the chief security officer and described in the environment list. For example, it may be complicated or impossible to use the latest patches and updates for old projects with specific environments. Perform a risk assessment for each exception.

• Unused services are disabled on all project hosts

Check that only services required for executing tasks are available and only documented ports and services are opened. All unused services must be deleted so they don’t interfere with the main project.

• Test environments aren’t exposed to the internet

Test environments, such as test versions of web applications, shouldn’t be exposed to the internet. If it’s necessary to provide access to a website to contractors or customers, for example, it’s better to use a VPN or whitelisting by IP address.

• Access attempts to all exposed services on the production and test environments are logged

All access attempts should be logged to detect intrusions and for incident response activities.

• Notifications are configured for failed access attempts to all exposed services on the production and test environments

In case there are several failed login attempts, notifications should be sent to the security officer or system administrator. Subsequent login attempts should be blocked with software such as fail2ban or sshguard.

• Build server/agents are physically located in an access-controlled environment managed by system engineers

Some small companies build product code on PCs located in developer rooms. In this case, make sure only those with permission can physically access these PCs. Another similar situation is using shared build agents on several projects.

Test data

• No test data is created from the production database

Test data shouldn’t contain information from production databases. If it’s necessary to work with a copy of the production database, all confidential data should be obfuscated.

Cloud infrastructure

For projects that use cloud infrastructure, it’s important to comply with various security guidelines and standards offered by both cloud providers and cybersecurity organizations.

When working with AWS, Microsoft Azure, and Google Cloud, it’s important to check that you meet all high- and medium-priority security controls according to the CIS AWS Foundation [PDF] and CIS AWS 3 Tier Web Architecture [PDF] benchmarks.

At Apriorit, we utilize CIS benchmarks as a security baseline for configuring cloud environments. Our developers have extensive experience auditing AWS infrastructure, Microsoft Azure environments, and Google Cloud environments.

Wireless networks

If your project has its own access points and routers, ensure that:

• All project Wi-Fi access points are identified and documented

All access points should be documented, mentioning their physical location and configuration.

• Default access point passwords are changed

Default credentials should be changed for access point admin panels and Wi-Fi networks.

• The Service Set Identifier (SSID) for project devices doesn’t contain confidential data

Make sure there’s no information such as a project or company name in the wireless network name.

Credentials and secrets management

Securing credentials is vital for every project. According to Verizon’s 2019 Data Breach Investigations Report, 29% of data breaches in 2018 involved the use of stolen credentials. You can increase the security of project authorization data by making sure that:

• Personal accounts are not used for project needs

It’s a common mistake, especially among small companies, for developers to use their personal accounts in third-party services (for example, AWS or GitHub) when performing project tasks. In this case, the risk of data leaks increases and centralized access management gets more complicated.

• Project accounts for third-party services are created using a separate project email and mobile phone number

It’s considered a good practice to use a separate email and phone number to create all accounts within third-party services needed for project purposes.

• Credentials are rotated regularly

All credentials used in a project should be rotated periodically, say, every 90 days. Also, credentials must be changed every time an employee with access to project credentials leaves the company. This minimizes the risk of data loss or data exposure caused by fired employees.

• MFA is enabled for services where available

Multi-factor authentication (MFA) reduces the risk of a data leak if any credentials are compromised. If you’re using Google Authenticator or similar services, special attention should be paid to preserving recovery codes. If you don’t have access to the device with Google Authenticator and the recovery codes are lost, then disabling MFA can take a while.

• Root accounts aren’t used for everyday tasks

Root accounts have lots of access permissions and are used for creating accounts with less privileges. Therefore, only a limited number of employees should have access to root accounts, and those employees should know how to use them correctly.

• Production secrets are encrypted and dynamically included during the deployment process

Popular secrets management solutions are tools like Vault from Hashicorp, Key Vault in Microsoft Azure, and Secrets Manager in AWS.

• Files and repositories are periodically checked for secrets that should be protected

You can use tools like git-secrets to avoid situations when secrets are committed to the repository.

• There are no secrets in plain text in build jobs, logs, or artifacts

All secrets have to be encrypted and stored in places that are available only for team members that need these secrets for their work.

Software dependencies

Project development requires the use of different components, like frameworks and libraries. Such software dependencies affect the security of the end product. This is why you need to monitor and audit all external components used for building your application. In particular, make sure that:

• All application dependencies are identified and documented

Document all components your application relies on the most.

• All components and libraries are periodically reviewed for known security vulnerabilities and licensing issues

You can do this manually by searching for vulnerabilities of dependencies in the NIST National Vulnerability Database, MITRE Common Vulnerabilities and Exposures Database, the Exploit Database, and The Community-driven Vulnerability Database.

• Components and libraries are independently scanned for vulnerabilities

The best option for checking application dependencies for known vulnerabilities is using automated testing tools. You can choose open-source tools like OWASP Dependency Check or enterprise solutions like WhiteSource.

Build process

Compiling software artifacts is one of the most important activities in the software development process. Any issues emerging at this point can harm both the performance and security of your application.

Apart from not storing secrets in plain text in the build jobs and not using root permissions for the build process, there are two more essential security practices that deserve your special attention:

• Builds for testing/release aren’t created on developers’ PCs

It’s strongly recommended to create a separate build system and build applications for testing/release only there. An exception can only be made when creating a PoC with a strictly limited development time.

• A separate SCM account with only read permissions is used for the build process

It’s a common mistake to use a developer’s personal SCM account during the system configuration build process.

Security testing

Finally, let’s talk about the key processes you should focus on during security testing:

• Risk assessment

Security issues have to be considered early in the development process. Before proceeding to development itself, review the list of project requirements and make sure basic security requirements are included.

• Security testing is integrated into the development process

The number of tools that can be used for security testing is enormous, so your precise choice depends on the project type and size.

• All required testing types are included in the testing strategy

These tests usually include unit testing, regression testing, static analysis based on coding guidelines, and dynamic analysis (based on scenarios and/or vulnerability tests and fuzzing).

• Manual penetration testing is performed for high-risk components

Pentesters should be involved in security testing of high-risk components such as online payment features and information about users’ bank cards to ensure the safety of critical data.

• Automated security testing is integrated into the build and deploy processes

Tools like OWASP ZAP and Burp Suite can be configured to automatically scan a web application after deployment.

Security audit — check. What’s next?

To get the most out of an internal security audit, you should create a list of failed security controls and an action plan to address these issues within the required deadlines. If you have no strategy to eliminate bugs and errors and allow for secure coding, there’s a chance your next audit will show the same security issues.

If you’re working on many projects, conducting audits on each of them will help you understand which development stages are the most troublesome and which issues occur most frequently. Thus, you can determine the processes your company needs to improve.

Consider arranging security awareness training for your whole company to minimize the risk that similar issues will occur in other products.

Last but not least, conduct regular audits to maintain the security posture of the project.

Conclusion

Understanding the importance of internal security audits is crucial for any project. Following the secure SDLC approach and focusing on processes is a great way to develop high-quality products with robust security.

By creating a checklist of security controls for each development stage and conducting regular security audits, you can cover the majority of weak points and eliminate some risks.

At Apriorit, we provide security awareness training for development teams to help them improve their skills and products. This training offers a long-term benefit, as trained specialists will most likely use the experience they’ve gained while working on other projects.

If you’re interested in getting an unbiased evaluation of your product’s security or want to implement a secure SDLC approach in developing your solution, contact us. Our experienced penetration testing team is ready to assist you in projects of any complexity.