UNDERSTANDING PROACTIVE VS. REACTIVE SECURITY

For most, the hectic ride of a start-up or a scale-up does not provide the time to build systems and processes properly. The same can be considered for an application security program. As you juggle between building the product and supporting new clients, there is very little time to properly build a security program. Instead, you might find yourself running ad hoc and random security tasks just to support particular clients or certain compliance mandates. It’s like ‘Application Security Whack-A-Mole.’​

KEY SUBJECTS

Throughout this guide, we will cover the building blocks of typical application security programs and we’ll identify at which stage of your growth they would be most useful. Planning ahead allows for a more strategic and thoughtful application security program with more favourable timeframes and budget requirements.​

Here at Software Secured, we have collected the information in this guide through a decade of working with start-ups and scale-ups. We hope that the information provided will help to bring your company to the next level in application security to support your growth and maximize your exit.​ Please reach out if you have any questions.

These are the essentials that businesses of all sizes should have in their cybersecurity strategy. They include security processes you can even include before you develop a single line of code.

• Training your developers on application security
• Choosing a security champion for your team

​

Best for ​Seed​ companies.

Post-seed, team size grows beyond 6-10 developers. In this stage, it's important to make application security a clear priority for developers. Security can be integrated as they write code.​

Your team can’t fix security vulnerabilities if they don’t know what to look for. Knowing the most prevalent bugs in application security programs is a top priority for any development team. Your team needs at least a well-rounded, base-level training in order to understand the top security bugs and how to find them. Training together is also helpful to ensure that everyone on the team has the same base level of knowledge so that they can work cohesively.​

Types of Developer Application Security Training​

1 General Security Awareness

​This is a high level security training for employees. Usually, security awareness training focuses on general security hygiene such as understanding the basic concepts of social engineering and other phishing attacks. Many CTOs make the assumption that technical staff are better equipped to deal with phishing and social engineering than other non-technical staff. While there is some truth to that, the attack scene is changing so fast. Software developers are becoming the prime target​ for social engineering as they have a higher level of admin access to multiple systems.

2 Secure Coding Best Practices

While most developers are easily able to identify what good code looks like, they don’t know how to identify secure code. Knowing the most prevalent bugs in application security programs should be a top priority for any development team. If your team doesn’t already have this foundation, we recommend at least a well-rounded, base-level application security training for your developers in order to understand the top bugs and how to find them. A good place to start is through an OWASP Top 10 training, which teaches developers the most important techniques to write secure code in any language.

3 Security Operations Best Practices

Not all security breaches happen through a phishing email or a SQL Injection in the application. There are other scenarios that can lead to a security breach. For example, the lack of security operations best practices including password storage, internal system onboarding, off boarding, setting up cloud infrastructure in an insecure manner, building secure images, etc.

Taking a training course does not mean that employee behavior regarding security will change completely. Different people will react differently to the information they intake during the training. After providing employees with the necessary information via training, you need to start thinking about how to encourage behavior change following the course.

In today’s software development culture, there is an ever-increasing need for management to drive empowerment within their teams. You need to seek out, identify, and empower someone who can act as your team’s security champion. Find at least one champion to start, and add more if they are available. As you grow, you may even consider assembling a Security Champions team​.​​

Security champions should have some security background or knowledge of cyber security, as well as being willing, able, and motivated to learn much more. They should be interested in staying up-to-date about evolving developments in the field. Your champion can be a current team member or a qualified contractor/consultant. A thorough knowledge of the team’s goals is necessary. A security champion needs to be a positive person that can offer diligent observations and constructive suggestions to the team.​

Your security champion will promote the best practices in application security. They will work with your systems architecture and engineering teams, and with DevOps and DevSecOps project leaders. You may choose someone who has excelled in their Application Security Training courses, as an example. Their knowledge of security threats and remediation methods will be of great assistance in preventing and eliminating security problems earlier in the software development lifecycle.

​Your security champion(s) will act as the reminder to be conscious about security in team meetings and design sessions.​​

Application security isn't one-size-fits-all. You grow into it as your business scales, your revenue increases, or your development team gets larger. Along the way, you can look into adopting new types of integrated analyses like:

• Threat modeling & secure design decisions
• Automated SAST & DAST tools
• Dependency checking
• ​Penetration testing
• Web application firewalls

Careful: they may not all be necessary for your business, but they aren't all interchangeable either. Choose the ones that are right for your business function, size, and goals.

Some describe security as boring, a progress-inhibitor or necessary-evil. We see it as a competitive advantage. Take DevOps for example. Netflix was able to weather the storm of AWS blackout​ due to their superior DevOps practices. While other AWS users were offline, Netflix remained operational and pretty close to full capacity. Application security functions exactly the same. Improving security practices helps you compete better on many fronts and avoid any disruption due to cyber attacks.

• Continuity. A repeatable process has a distinct start and end point.
• Automation. Automatic processes eliminate the barrier to execution.
• Scheduling. This process cannot be forgotten under the distraction of tight deadlines
• Measurability. Developers must be able to draw insights and make decisions from the results of the analyses.​

Source: TechAhead​

Using the Continuous Integration approach as your CASM framework is a great choice as it provides you with each of the continuity, automation, scheduling and measurability factors.​

If the CI/CD approach cannot be used, then a security code review process is a possible alternative. However, the code review process will likely provide limited results in comparison. Regardless, all reported or found bugs should be recorded and prioritized so that they can be dealt with during the next scheduled sprint backlog event.

The types of integrated analyses processes included in this section, when applied together, will form the bedrock of your application security.

Best for Pre-Seed companies.

​​With limited budgets, access to additional resources and commercial tools is likely unavailable. Threat modeling is the most economic activity to bake security into the SDLC. Additionally, many design decisions are made at the pre-seed stage. These decisions can be difficult to change in later stages, so it's important that they are considered for security through threat modeling.​

​Threat modeling is the ultimate shift left approach. It can be used to identify and eliminate potential vulnerabilities before a single line of code is written. Employing threat modeling methodologies should be your first step toward building networks, systems, and applications that will be secure by design.​

One reason that threat modeling is performed as a first step is to obtain an objective viewpoint of the big picture for the project and define the locations of potential security vulnerabilities. This can be done once the design has been defined conceptually.

Obtaining this viewpoint will be helpful in choosing the threat modeling methodology that best fits the project. This step is a mission-critical decision, so it will require that some investigative research be completed to ensure that the right choice is made.

​Today’s threat modeling is evolved from practices that were developed nearly thirty years ago, such as drafting process (or data) flow and attack tree diagrams. Those practices led to the development of the well-known methodology STRIDE​, discussed later in this section.

​Though STRIDE is a highly popular and effective methodology, several others are also available. Some are more appropriate for different IT disciplines or have different focuses, such as applications instead of networks, for example.​

No threat modeling technique is perfectly tailored to a specific use. You should choose the one that most closely aligns with your goals. However, your DevOps team should be encouraged to adapt or customize threat modeling techniques to better fit their specific use case.

​Creating a process or data flow diagram is one of the best methods you can use to gain a top-level view of your system or application and its interaction points. Frequently, flow diagrams can be adapted from existing network architecture diagrams. Diagrams can be created with a pen and paper, or by using an application like PowerPoint or LucidCharts. Flow diagrams are useful tools which are more helpful and easier to interpret than trying to review the process or data flow in a textual design document alone.​​

Source: Christopher Kalodikis

Start by assessing your system or application, and note where and how each entry point interacts with all of its associated external entities. One of the best formats for quickly and dynamically creating a threat model is the use of a whiteboard in a team environment. Determine which assets could be infiltrated by intrusion at each noted entry point. Rank those assets by the target’s value. The higher the value, the more likely that asset will be of interest to a hacker. Then, identify the known possible threats associated with each identified vulnerable asset.​​

The next useful exercise in threat modeling is the creation of an attack tree diagram that integrates all vulnerability information that has been accumulated. This is a great aid in determining all potential threats against either infrastructure or application(s). Using it, you can identify specific threats, their possible entry points, and the potential exploitation of each threat. A thoroughly defined attack tree facilitates the ranking of threats, too.​

Source: eTutorials.org

After fully defining the flow and attack tree diagrams, examine how the system or application will permit legitimate access to resources. Identify the external entities that will need to have such access. Establish the process by which that access will be granted. Determine the authentication and encryption methods to employ. The strength of those measures should be relative to the value of the asset(s), to ensure that the required trust level will be maintained.

This worksheet breaks down the six main categories of vulnerabilities in the STRIDE threat model. You may use it to help guide your own threat model. Use the space provided on the left to help record and track in your early stages of building the threat model.

Other popular threat modelling methodologies that you may wish to explore are PASTA, VAST, Trike, OCTAVE, and NIST.

NOTE: Going forward, remember that your threat model is a living document and needs to be constantly reviewed and updated. After a system wide threat model has been performed it can be valuable to perform mini threat models as a secure engineering design requirement.​

Regarding frequency:

• Full initial threat modelling should be performed and repeated annually.
• Delta threat modelling should be performed on any newly proposed feature or significant change at the design phase.​

Best for Seed companies.

​​Static code analysis is a great way to catch low-hanging fruit in code paths that are not exercised often. It also acts as a way to standardize security across the program. Many enterprises request that their service provider have a SAST tool in place.

Static code analysis is a methodology used to locate vulnerabilities in application source code. Typically, it is an automated process that is performed prior to compilation, without code execution, to ensure that the code meets industry standards, leading to establishing a sustainable, secure program.​

The testing is done with full knowledge of the program’s internal structure and the expected logic paths. Knowledge of the implementation is required. Therefore, the application’s finalized design document is a prerequisite to test preparation and execution. Due to the transparency in the static code analysis testing process, it is referred to as a White Box Test.

The testing itself is a time-consuming process. Fortunately, there are automated testing tools available. Static code testing should be conducted by an expert with considerable experience in this discipline.​

When implementing automatic SAST into your development, the following steps are recommended:

• Expand peer code reviews and evaluations to include security code review.​
• Implement SAST on new code whenever a build or push is performed.​
• ​Include a process for peer approval and validation of any exceptions or reclassification of security issues. If a vulnerability is found that has a medium severity or higher, escalate the issue to utilize your security or champion(s).​​
  
• Implement a full codebase scan every time a major version releases, or quarterly if there hasn’t been a major version update recently.​
  
• Consider implementing unit testing for security issues which have been a historical, common, or high-risk area.
• ​Perform quarterly scanning of code repositories’ configurations, history, exposure, and management of secrets. All passwords, keys, or secrets should be kept in secure cryptographic storage, and never in the code repository. Any previously exposed keys need to be updated.
• ​Confirmed critical severity findings should be addressed before release. See Chapter 4 for how to identify these.
• ​Perform a minimum bi-annual auditing of code access controls.​
  

Best for Seed companies.

Integrating dynamic analysis is a great way to capture low-hanging fruit in production. It is an easy win on a vendor security questionnaire.​

Best for Pre-Seed companies.

Since the number of dependencies used by applications on average continues to grow as the business grows, it is important that businesses integrate dependency checking early. This is also beneficial to ensure your business is not stuck with inherently vulnerable components, which become very expensive to replace later on. Dependency checking should be a primary tool for B2B companies, as visibility for supply chain software is very high.​

However, servers could be misconfigured, which could then provide an entry point for breaches. If an administrator were to replicate a misconfigured server’s image to create additional servers, they would be multiplying the same vulnerability. There is always a requirement for testing, risk identification, and mitigation in cloud-based enterprise architecture.

Best for Seed companies.Penetration testing as a service (PTaaS) provides more than just a one-time annual pentest. PTaaS grants constant access to a team of security experts, meaning code can be tested as it ships out. Security experts are also available for consultation on any other area of your application security, including design, threat modeling, results analysis and more. It is important to integrate security testing early in your business to set up efficient workflows and gain an understanding of security concerns while the team is smaller.​

Penetration testing (also known as pentesting) often uncovers weaknesses that would otherwise go undetected during the procedures applied in Chapter 2, subsections 2.2 through 2.6. As the tests are human-driven, the pentester is able to apply their own experience and closely simulate a real cybersecurity attack. An additional benefit of penetration testing is that it takes more time to understand an application's unique business logic. As such, the penetration tester will design specific application test cases for each application.​

Types of Penetration Testing​

Best for Round B companies.

As your business continues to grow and service offerings expand, the attack surface increases. At this point, it might be more difficult to stay on guard with each application. A WAF acts as an another line of defense against attacks. It works in addition to any other controls.​

If a WAF is ever updated or swapped for a different vendor’s product, you could suddenly expose undetected application weakness if Chapter 2, subsections 2.2 through 2.7, were not implemented. Frequently, WAFs can be bypassed or circumvented by attackers – it just takes a little longer. Think of comprehensive security as layers of an onion. If there are too many layers for an attacker to break through or overcome, it is often not cost-effective to attempt an attack at all.​

Best for companies in Round A or higher.

In Round A, your company begins playing in the big league, meaning you're now a worthy target for hackers. Logging and auditing signals to your customers that you have a mature SDLC that can withstand attempted attacks. This security measure can help close bigger enterprise clients.

​

Effective logging and auditing can be a bit of a balancing act. You need to log enough to be able to perform a forensic analysis, should you ever have a breach or other cause to validate the activity performed on a system. However, it is not desirable to log so much that you expose anything sensitive about the system or its users. Refer to the OWASP Top 10 2017‒A10: Insufficient Logging & Monitoring​.​​​

​Best for companies in Round A or beyond.

​SLAs are typically mandated by larger clients. As one of the goals of a Round A company is to target and close new large-size vendors, this step should be started in the Round A stage.

For any security program to work, it will need to have consistency, calibration, and accountability. The following specific information must be defined in your organization’s Service Level Agreement (SLA):

• What needs to be done in any security relevant situation;
• How often, by whom, by when; and
• An effective way to track your organization’s compliance to its own security policies.​

​The internal service level agreement (SLA) defines a contract between the security and software development teams. While security teams are responsible for identifying risk, developers are the ones in charge of fixing found issues.

Where possible, automate and integrate all components of security issue analysis. Anything that cannot be automatically performed or integrated should be added to some form of a release checklist.​

​Specific internal SLAs for vulnerabilities discovered during scanning or pen-testing should be assigned a severity level appropriate to the specific weakness. These could vary based on the risk potential of the specific target or context. The chart below is an example of an SLA.

Known open security issues and/or defects should be tracked in a common database or issue tracking system. This database should be regularly maintained and audited by a security focal leader. Any collection of issues approaching or expiring the SLA date should be discussed among management, security focals, and development to ensure that nothing is forgotten or overlooked. Regularly scheduled meetings with stakeholders could be an ideal way to discuss issues together.​​

Your organization should have a publicly visible process by which to receive responsible vulnerability disclosures by third parties (e.g., a portal in which to log them or a secure email alias, published somewhere on your website, under security policies). Third party reporters could include prospects, customers, customer pen-testers, security researchers, bug bounty hunters, etc.​

​It would be advisable to impose a set of SLAs for external reports, similar to internal SLAs but containing more aggressive deadlines.​

Communication with third parties about potential vulnerabilities should be carefully managed. How you handle these reports and the level of security culture demonstrated to these third parties is critical. It can often go a long way toward either improving or diminishing your organization’s reputation with regards to security.

A note regarding bug bounty hunters: if your application or system has undergone several rounds of pentesting and you are more confident in your security posture, consider establishing a bug bounty program with clear rules and guidelines. Pay third party reporters for their contributions. However, it is usually not advisable to do this in place of pentesting as it can become very costly if your security posture is not yet fully matured.​

For example, many security researchers will disclose the vulnerability details publicly, in a blog or security conference, to help advance their own reputation. They are well within their rights to do so and were kind enough to tell you about the issue first. Therefore, debating the issue with the third party reporter or threatening legal action would not be recommended in this situation.​

A common external responsible disclosure period is about 90 days from the initial report. It is usually best to employ the following steps when dealing with a third party reporter:

• Thank the reporter for reporting the issue to you.
• Follow up with them when you have confirmed the issue is legitimate (or request more details from them, if needed).

• Ensure there is a fix implemented (and communicated to the reporter, in follow-up) before the disclosure period expires. This will serve to avoid potential embarrassment or impact to your organization’s reputation.

External third party security issue reports can be valuable assets when handled correctly and addressed within the time-frame that you have specified.​

No security policy should be completely rigid. There are going to be situations where a team cannot practically resolve a particularly complex security issue within the defined SLAs. Also, there will be situations where it might make more business sense to accept some minor risk versus expending major resources or costs to address it.​​

​A good security program will include some form of exception process. Document when and how a development team or other stakeholders can present their case to senior decision-makers to request approval to override SLAs or accept risk. There are cases when this might be preferable instead of fixing some security issues. Be sure to clearly document these decisions.

​Risk should be clearly measured. The DREAD system could be used to quantify the risk, similarly to the way in which it was employed in threat modelling (refer to Section 2, subsection 2.1). This approach will help assess any potential asset damage, exploitability, impact to users, and discoverability, versus the business case and costs to fix the weakness. This process should be the exception to the norm and only used selectively and infrequently, after all other feasible options are considered.​

It is our hope that this guide will serve as an inspiration and reference for the current best practices available to VPs of Engineering, CTOs, Security Champions, and Developers in their quest to develop reliable, sustainable, and secure networks, systems, and applications.

We wish you every success in your business and hope you achieve the growth necessary to exceed your goals.

If there is anything we can do to assist you with security in your development projects, we would be pleased to discuss your requirements with you. Our services include:

• Penetration Testing as a Service (PTaaS)
• Application Security Training
• Secure Code Review
• One-time WebSec, AppSec and IoT Penetration Testing options