Since the release of ChatGPT, people have asked us how Security Compass will embrace Generative AI and, more broadly, how application security will change as a result.

We are well into the journey of helping our customers build more secure applications leveraging generative AI, including new AI content in SD Elements and SD Blueprint and a Kontra course on OWASP Top 10 for LLM. This blog post will cover upcoming capabilities we will release that leverage LLMs.

Navigator

The field of Generative AI has evolved rapidly since, and the possibilities about what we can do today and what we might be able to do tomorrow have changed with it. Much discussion has revolved around the potential for LLMs to create vulnerable code since they are often trained on open-source code containing vulnerabilities. Applications represent a major attack vector. However, application security and development teams are constrained by the accelerated pace and frequency with which they release software across diverse environments. This leaves them with limited time to implement the necessary security measures to meet business deadlines. With Navigator, our goal is to make it easier for organizations to build applications that are secure and compliant by design at scale without compromising the speed of delivery.

At Security Compass, we have amassed the world’s largest knowledge bases of expert curated secure coding practices in our content library. This library is not a simple collection of articles from the Internet. Our internal research teams, along with third-party experts in specific technical domains, curate, edit, and categorize software weaknesses, threats, countermeasures/controls, code samples, Just In Time Training videos, and regulatory mappings. Combined with our extensive application security training catalog and hands-on Kontra labs, our over 13,000 content items for secure and compliant coding practices are unrivaled. Moreover, we regularly receive feedback about the real-world applicability of content from end users, resulting in a feedback loop that allows us to further refine content effectiveness. The end result is data that, combined with the strengths of current LLMs, can bring significant benefits to our users.

Navigator is the first feature we are shipping in beta in July. It follows our strategic theme of Intelligent Content, which provides the following benefits to end users:

• Context-specific guidance: Security by Design tools have generalized content designed to work in many contexts and environments. However, sometimes, the general content misses the details necessary to help users answer in specific contexts. With Navigator, users can ask in-depth questions and get contextual answers pertaining to threats, weaknesses, countermeasures, implementation guidance, how-tos, regulations, and survey answers specific to their project. Instead of having access to a countermeasure like “T8: Use Consistent Error Handling for All Authentication Failures”, users can ask clarifying questions like “How can I implement T8 in my Ruby on Rails application?”.
• Cover new technologies and standards: Even though SD Elements has the world’s largest secure coding knowledge base, there are cases where users need to ask questions about technologies or compliance requirements not covered out of the box. For example, “How can I salt and hash stored passwords in Rust?” or “How does China’s Cybersecurity law relate back to SD Elements countermeasures?” Navigator will dynamically provide responses trained on the SD Elements knowledgebase.
• Translate to different languages: Using Navigator, users can translate content into different written languages. For example, “Translate T15 into Spanish”
• Ask questions about SD Elements: Users can quickly find answers to questions about SD Elements, such as “What’s the relationship between the countermeasure risk rating and the weakness priority?”

We expect to uncover many more exciting use cases of Navigator as we enter the beta and hear from our users. If you are interested in participating in this beta, please contact beta@securitycompass.com for more information.

Navigator Product Tour

Threat Model with Anything

According to our primary research in The State of Security by Design and Threat Modeling in 2024, scalability and resource constraints are the 2nd and 3rd most common challenges with threat modeling. Using SD Elements or SD Blueprint is one of the fastest methods to ensure Security by Design, reducing the time to perform security activities by 90%+. However, we recognize that there is even more room to speed up the activity.

That’s part of the motivation for releasing the ability to scan GitHub repos to model applications in our 2024.2, which complements the custom modeling automation our most sophisticated enterprise customers have used for years.

Imagine, however, taking any image or document you have to describe a system—from requirement specifications to architecture diagrams to readme files—and having the system automatically create a relevant system model, threat model, and corresponding security requirements. This is the vision of what we call “Threat Model with Anything,” and we are making fundamental advances toward that vision in 2024.

Importing Any Image

Many organizations use diagrams or visualization tools to represent threat models, from diagrams on whiteboards to Visio, Lucid Chart, PowerPoint, etc. Organizations often ask, “Could we use the diagrams we already have to drive Security by Design in SD Elements and SD Blueprint?” Our team has begun work on a feature that leverages advances in AI to recognize any threat model image and convert it into an SD Elements and SD Blueprint diagram.

Importing Any Image Prototype Product Tour

We expect to release this functionality in beta to customers who opt-in within the next four months. We will work closely with beta customers to determine any inaccuracies and improve the models before promoting the capability into general availability, which customers may opt-out of. If you are interested in participating in this beta, please contact beta@securitycompass.com for more information. This is an excellent opportunity for early adopters to experience the benefits of importing any image and help shape its future development.

Importing Any Text or Document

Advances in foundational Large Language Models (LLMs) have also improved the ability to recognize text and make meaningful assumptions. Our next advance will allow users to take unstructured text as well as some text-based files, interpret them, and use them to answer questions in an SD Elements project automatically:

Users will have a new option to import files that describe technical design or business context.

We want to make it easy to integrate with existing tools and automate via APIs

We are training AI models to automatically populate surveys or generate diagrams

Turn your design documents into threat models that identify critical security requirements

We expect to release this functionality in beta to customers who opt-in by early 2025. Just like the ability to import images, we will work closely with beta customers to identify and fix inaccuracies before general availability release. Ultimately, we expect to leverage the same underlying capabilities to be able to understand source code or any text-based document to more accurately model a system.

Future Direction

Software written in natural language is the evolution of coding – just as compiled and interpreted programming languages are converted into assembly code, we are quickly transitioning into a world where software is expressed in natural language that is subsequently converted into code. In this world, we believe people will need solutions like SD Elements and SD Blueprint that express security and compliance requirements in natural language to ensure their systems are secure and compliant with sufficient audit evidence to meet emerging regulatory and liability requirements.

There are two other themes for our long-term product evolution that will leverage advances in Generative AI:

• Intelligent Content: Leveraging our extensive knowledge base will allow us to solve the problem of “generic” requirements, ensuring they are context-specific for their particular application and code base. Navigator is a first step in this direction. Moreover, it will help us solve one of the key challenges organizations have – translating their own broadly written corporate standards into the kind of specific, actionable content for development teams that SD Elements and SD Blueprint offer out of the box. We’ve already begun to make some in-roads in this area with our research team behind the scenes.
• Close the Loop: Today, SAST, DAST, and SCA tools generally run entirely independently of threat models. They may be missing the assessment of critical security and compliance risks. Imagine a world where your security and compliance requirements feed into an assessment engine, and that engine validates the implementation of the requirements. Instead of relying solely on “clean” scan results to ensure an application is secure, you have the assurance that your system was assessed for all the relevant security and compliance risks. Even if the implementation is imperfect, it would be a significant improvement to the status quo. This vision we call “Close the Loop,” and we believe it is one of the most exciting capabilities to come. Early experiments of using LLMs for security scanning show promise. As LLMs and security scanners that leverage LLMs improve, we will tightly integrate with these tools and envision launching scans directly from SD Elements. Coupled with “Threat Model with Anything,” this will allow for true end-to-end automated application security.

Learn More

Contact us today to learn about our latest advancements and how they can benefit your organization. If you are interested in participating in this beta, please contact beta@securitycompass.com for more information.

Visit Security Compass to get in touch and discover more about our cutting-edge solutions.

The post Security Compass AI appeared first on Security Compass.

What is the Cyber Security Framework (CSF)?

CSF is a voluntary framework initially designed for critical infrastructure organizations to measure, manage, and improve their cybersecurity posture. Its flexibility, breadth, and conceptual simplicity, along with having the backing of NIST, means that many organizations across all verticals and around the globe have adopted the CSF as a primary tool to communicate cybersecurity posture and priorities.

A common use of NIST CSF is for technology executives such as CISOs and CIOs to report to boards of directors on current and target states related to cybersecurity posture. According to IDC, over half of Fortune 500 companies with US headquarters have adopted the NIST CSF as their primary control framework for cybersecurity. Many international brands have cited NIST CSF in their annual reports or other public documents, including T-Mobile, Nielsen, Blackrock, TransUnion, Thompson Reuters, and Petrobras. Global consultancies such as PriceWaterhouseCoopers (PWC) offer guidance to boards on the CSF, and the National Association of Corporate Directors (NACD) cites CSF in its Cyber Risk Oversight Handbook.

While many other frameworks and control catalogs exist, the CSF is unique in its widespread acceptance across regions and industries by non-technical stakeholders.

The CSF’s Role in Shaping Cybersecurity Programs

Cybersecurity has an ongoing and often heated debate about the value of compliance vs. mitigating risk. Security practitioners often bemoan focusing on “checking the box” of compliance vs. spending time and effort on the organization’s most significant areas of risk. The debate will likely continue forever, but one thing is clear: compliance will always be a substantial driver of cybersecurity programs.

Finding the appropriate spend of time and effort in cybersecurity is no simple task. Leadership teams in any organization often seek concrete, measurable goals to help allocate resources for domains like cybersecurity. Measuring against an internationally recognized and credible framework like the NIST CSF can often have the additional benefit of satisfying many stakeholders, including auditors, regulators, and shareholders. Moreover, it creates a defensible position in the event of a security incident – a major topic of conversation at boards due to the SEC’s new rules on incident disclosure.

Organizations that adopt CSF often use Profiles that measure the current state across the various control categories, define a target state, and then use the delta to help build a roadmap for their security program. CISOs or other senior executives are often asked to periodically report progress to the board on that roadmap against the CSF target state.

The high-level visibility of the CSF often means that the entire cybersecurity program and budget are heavily influenced by the roadmap to achieving the target state. While the CSF is flexible and not prescriptive, the reality is that for many organizations, CSF creates a world of haves and have-nots for cybersecurity: anything described in the CSF Core and on the roadmap to target state is a priority. Anything that does not help achieve target state compliance is a lower priority unless it is a critical (i.e., imminently exploitable) risk or leaves the organization in non-compliance with regulatory requirements.

The CSF and Software Security

Partially because it was developed for critical infrastructure organizations rather than software manufacturers and partially because widespread awareness and acceptance of the importance of secure software development practices was relatively low compared to today, the NIST CSF 1.0 and 1.1 core did not contain many explicit references to software security. Many categories and subcategories could be interpreted to include software. For example: “ID.RA-5: Threats, vulnerabilities, likelihoods, and impacts are used to determine risk“ or “PR.IP-12: A vulnerability management plan is developed and implemented”. However, in most cases, the scope was broader than software. Moreover, the concept of security by design and integrating software at the beginning of the development process was not mentioned.

Secure SDLC and security-by-design are large programs that require organization-wide support and executive buy-in to be successful. When deciding which programs to fund and allocate headcount to, many organizations decided that the cost/benefit of investing in an extensive program like this was simply not worth it if it wasn’t on the CSF target state roadmap.

The Importance of Secure Software Development in Today’s Cybersecurity Landscape

In 2021, after many high-profile incidents, the president of the United States issued an executive order on cybersecurity that specifically called out software supply chain security. This was followed by a wave of government actions related to software security, including:

• Cybersecurity and Infrastructure Security Agency (CISA) and other governments around the world began to push the importance of secure by design software,
• NIST published the Secure Software Development Framework
• The Federal Communications Commission (FCC) established the Cyber Trust Mark program
• The Food and Drug Administration (FDA) pushed to improve product security of medical devices
• The European Union introduced the Cyber Resilience Act and proposed changes to liability to include software vulnerabilities

Spotlight on Platform Security: A New Paradigm in NIST CSF 2.0

One of the most significant changes to NIST CSF was its intended scope. Instead of focusing primarily on critical infrastructure, NIST CSF 2.0 is now designed for any organization.

NIST introduced the Platform Security category under the “Protect” function: “The hardware, software (e.g., firmware, operating systems, applications), and services of physical and virtual platforms are managed consistent with the organization’s risk strategy to protect their confidentiality, integrity, and availability.” Under platform security, NIST added a subcategory that specifically references secure software development: “Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle.” Including this subcategory means anyone who builds software and wants to implement a secure SDLC program can do so knowing it will align with CSF.

Assessing Secure Software Development Current State

CSF defines four tiers for assessing the current and target states:

(Source: NIST CSF 2.0)

Most organizations looking to improve platform security will likely target Tier 3 or 4 in their end state. The NIST SSDF provides a comprehensive set of controls specific to secure development. In our experience, many organizations have implemented security testing and/or scanning and developer education but have not otherwise broadly rolled out secure SDLC activities such as threat modeling, defining security requirements, ensuring code integrity in the build process, etc. These organizations will likely self-assess as Tier 1 or Tier 2 in this category.

Next Steps: Achieving the Target State

Organizations looking to Target 3 or 4 for secure development should consider building a roadmap based on the NIST SSDF. We have published a guide to help you comply with the SSDF.

This is an excellent opportunity to build broad support for security by design. We recommend adopting the 3E framework to help ease the organization into the cultural change necessary: Educate development teams, Embed security ownership within the teams, and then Empower the teams to integrate security by design.

Conclusion: The Future of Software Security with CSF 2.0

The global influence of NIST CSF is unparalleled. Combined with the regulatory changes and other government actions related to software security, integrating security into the SDLC will no longer fall into the “have-nots” of a cybersecurity program. Practitioners who have seen their initiatives shelved year after year will finally have the organizational backing to push for fundamental changes in software development.

The downstream impact of software product manufacturers building more secure software will be felt by everyone. Fewer patches involving known, preventable security defects will lead to fewer incidents and increase public trust in technology. This is the very vision of Security Compass.

Contact us if you want to learn more about secure software development and how to start your program.

The post Navigating the New Frontier: NIST Cybersecurity Framework Version 2.0 and Its Emphasis on Software Security appeared first on Security Compass.

In May 2023, attackers exploited a SQL injection vulnerability in MOVEIt – a widely used file transfer service. Organizations across the public and private sectors were impacted, with highly sensitive PII, including health information about newborn babies. The ongoing proliferation of software vulnerabilities like this has led to more people calling for a security by design approach.

At Security Compass, we strongly believe in security by design. Empowering teams to build secure software by design is our company’s mission. The costly legacy “find and fix” method for securing software is insufficient to make a material improvement in cybersecurity. Security by Design is not just about preventing threats; it’s about instilling confidence in every stakeholder, from the boardroom to the end user. We support software manufacturers to integrate security across the development process, right from the requirements stage, which in turn enables them to take ownership of security outcomes for their customers.

Benefits of Security by Design

Integrating security by design with the appropriate people, process, and technology is not only good for risk management – it bolsters the bottom line. With over a decade of experience in implementing our solutions, we’ve helped companies around the world achieve secure-by-design outcomes:

• A leading building supply company reduced cost and time to market for security requirements by 30%, and increased collaboration between security and development
• A large bank reduced risk, improved visibility and cut the time to assess risk by over 90%
• A Smart Home Products brand successfully embedded a Security Champion in every development team
• A global consultancy lowered their threat modeling process time from over 230 hours to 60 hours
• Several federal government organizations reduced their time for compliance activities from months to days

These outcomes ultimately yield faster time to market, more revenue and lower risk.

Navigating Regulatory Changes in Software Security

Governments and industry standards boards are taking notice. In 2023, the governments of the United States , Canada, Australia, United Kingdom, Germany, Netherlands, New Zealand, Czech Republic, Israel, Singapore, Korea, Norway, and Japan published guidance on security by design. An executive order in the United States mandates secure software practices for vendors who supply software to the federal government. OWASP introduced “insecure design” as a top 10 risk in 2021. States and federal governments are starting to write laws or bolster existing ones for Internet of Things vendors to incorporate security by design. Proposed legislation for hospitals in New York requires security by design practices. Moreover, some countries are considering shifting liability for breaches to software manufacturers with safe harbour provisions for those that incorporate security in the development process. Even if you ignore the business benefits, not incorporating auditable security by design practices is likely to leave any software or hardware manufacturer at risk for regulatory noncompliance and maybe even liability for breaches at customer sites.

Overcoming Common Challenges in Security by Design

While the business benefits and regulatory requirements are compelling, security by design is not a “plug and play” solution. Most people think of security as a quality that you test for: security vulnerabilities are scanned in code or discovered in a penetration test. The idea that you can prevent ever having a vulnerability takes a mindset shift. Over the years, we’ve seen a number of anti-patterns emerge from organizations who pursue security by design without putting in place the appropriate steps to adjust for the mindset shift.

• Inattention to change management: Because the business benefits of security by design seem obvious, many organizations rush into embracing new tools and techniques without considering the impact of changes to software, product and business teams. Fortunately, many organizations have already learned this lesson from other initiatives and have formed change management best practices. Classic techniques like stakeholder analysis, incentive alignment, early involvement of potential detractors, and communicating/learning from the results of pilots can prove effective.
• Moving too fast: One of the most challenging realities of embracing security by design is that it creates new work for teams. For example, development teams who embrace threat modeling and/or defining security requirements have more work to do up-front in the development process, which in turn takes away time from writing code in fixed-length development sprints. This is often at odds with product management/business goals of shipping more capabilities to users within the sprint. If a security team tries to inject 100 new security requirements for a development team to analyze and potentially action at the beginning of a two-week sprint, the effort will almost certainly fail because even reviewing the requirements will leave little time to complete features. Successful implementations often start with a crawl-walk-run approach: begin with work that requires a small investment in time, such as implementing a single, small security requirement. While this approach doesn’t materially improve risk posture right away, it helps build acceptance to the concept of security by design. As development teams become accustomed to taking on security work in planning, they can slowly increase the time investment and reduce more risk. Ideally, teams plan for proactive security work alongside other feature work on a regular basis.
• Begging the question: When organizations haven’t holistically embraced security by design, champions of the initiative often want to prove its benefits with a pilot or limited rollout. Without a mandate, they ask development teams to participate voluntarily. However, when faced with more immediate priorities such as feature work, development teams often drop voluntary work and do not perform tasks such as threat modeling or defining security requirements. The pilot fails to provide proof, and detractors point to the lack of traction as evidence that security by design doesn’t work. In our experience, voluntary efforts from individual developers to implement security by design rarely work. Instead, business and product stakeholders need to embrace the concept of security by design and allocate sufficient time to truly perform security by design activities.

The 3E Framework: A Rollout Strategy for Security by Design

If you are leading security by design at your organization, there’s a good chance you have faced or will face some of these anti-patterns. It can be frustrating to be up against a mountain of change resistance for an initiative that has such obvious business benefits. In periods of constrained budgets, starting an initiative that will require people, process and technology support is especially difficult. Fortunately, we’ve seen enough organizations succeed in rolling out security by design that we’ve identified a common pattern we call the 3E framework: Educate, Embed, Empower.

1. Educate: When it comes to security, ignorance is bliss. Development teams have a false sense of security because of clean penetration tests, or a broad cybersecurity compliance as SOC2 compliance. Training development teams on basic security awareness allows them to better understand the true breadth and complexity of creating secure systems. Successful security by design rollouts often start with this awareness as a precursor to processes that impact development processes, such as threat modeling. In parallel, champions begin the process of soliciting buy-in to security by design from executives by focusing on the business benefits of lower costs, reduced risk, and faster time to market.
2. Embed: For security by design processes and technology to work, they require people to champion them. Security champions are developers who have a strong interest and above-average knowledge of security. They are embedded within development teams and serve as the ideal owners for activities such as threat modeling and defining security requirements. Absent these champions, security by design initiatives often falter with lack of ownership.
3. Empower: Once development teams have been educated, executives have bought into the initiative and security champions are embedded in development teams, the groundwork has been laid for empowering development teams to rollout processes like threat modeling and security requirements. This is when organizations really begin to experience the business benefits and gain an advantage over competitors who are still stuck in costly “scan and fix” approaches to secure software.

Alongside these steps, successful rollouts often take into consideration:

• Metrics: Tracking KPIs and seeing progress over time helps to illustrate the business benefits. This often involves augmenting reactive metrics like defect density with proactive ones, like compliance against internal policy for security requirements.
• Budget: Any successful security by design program encompasses people, process and technology. Organizations need sufficient budget in all three in order to reap the significant business benefits.

Real-World Success Stories: Implementing Security by Design

One large manufacturer we worked with followed this strategy. They started with a large-scale roll-out of security awareness training for multiple roles across the development teams. They leveraged industry accreditation with ISC2 to embed security champions inside the development teams. They subsequently rolled out security requirements and threat modeling across teams and saw significant reductions in risk; penetration tests started to turn up a few findings in product teams that incorporated all of these steps.

The amount of change required isn’t always appealing to security and development teams who are strapped for time. Acknowledge this with your wider team and encourage empathy across functions as you balance speed to market with sharing the responsibility of designing and building secure applications. The alternative to security by design or the status quo, where customers deploy products with known, preventable vulnerabilities and expose themselves to being exploited in the wild and incurring even more damaging costs like loss of business and loss of customer trust.

Security by Design is not a luxury—it’s a necessity. As the CEO of Security Compass, I firmly believe that when we prioritize security from the start, we’re not just building software; we’re enabling a world where we can trust technology. Let’s shift the paradigm from security as an add-on to security as a default, ensuring that every customer inherently receives the secure products they deserve.

How Security Compass Can Guide You in Security by Design

If you build products with software, you can get started with security by design today. Start by assessing yourself on the 3E framework: are stakeholders educated? Have executives bought into security by design? Our role-based training can help you get started. If you’ve moved past education, have you embedded security expertise by forming champions? Our partnership with ISC2 to offer the Software Security Practitioner accreditation is a great way of validating security expertise for champions. If you are ready to empower development teams, SD Elements helps integrate threat modeling, security requirements, and compliance into the development process.

Contact Security Compass now to learn how SD Elements can help your organization achieve security by design, minimizing risks while maximizing efficiency and compliance.

The post The Case for Security by Design appeared first on Security Compass.

I’ve been talking about this challenge my whole career. The current state of best practice is to comply with broad cyber security standards and frameworks that may, but in practice, often do not adequately address software security. In 2021, when president Biden issued an executive order citing software security, I was excited to see a significant first step. The release of the NIST Secure Software Development Framework (SSDF), which finally meant an industry-wide standard around secure software, was a significant related development. The EO applies to software manufacturers who sell to the US federal government. Shifting liability to manufacturers is much broader reaching.

The ramifications of adopting security in the software process are huge and will be costly. Software liability has been so thorny because producing 100% secure software is practically impossible. Thankfully, the strategy introduces the concept of a safe harbor, where organizations can shield themselves from liability by following established best practices, such as those in the SSDF. In doing so, they are following the pattern already established by other standards like the Payment Card Industry (PCI) Software Security Framework (SSF), where organizations can attest to their security by following a Secure Software Lifecycle approach. 

The impending changes will force companies to move away from a testing-only strategy and incorporate more robust security throughout the development process. It will also necessitate audit trails where they don’t usually exist, such as in software design. Security-by-design was the topic of focus by Cybersecurity and Infrastructure Security Agency (CISA) Director Jen Easterly in a recent address at Carnegie Mellon University.

Inevitably, some people will look at this proposed strategy and wait to react. After all, proposing and passing legislation through congress is likely years away. This approach would be a mistake. From our experience, the act of changing software processes across a company to integrate security in every phase can take years since it involves process, behavior, and skill changes. Now that the possibility of software liability has been opened, governments worldwide will take notice, and other countries will pass liability laws even if the US does not. Retrofitting old code into the new process will be onerous; the right time to start planning is right now.

Next Steps

If you’re looking to start with the NIST SSDF, take a look at our whitepaper.

The post White House National Cybersecurity Strategy Takes on Industry’s Third Rail: Liability Shift from Users to Software Manufacturers appeared first on Security Compass.

What Is a Red Team Exercise?

Over the last few years, the term “Red Team” has become a buzzword in the information security community. The varied uses of the term within the industry can be confusing. Some organizations call their internal offensive security teams “Red Teams,” with responsibilities ranging from web application penetration testing to full-blown red-team operations. For the sake of this discussion, we will define a Red Team engagement using a common definition that appears outside of military contexts:

Red Teaming is a full-scope, goals-based adversarial simulation exercise that covers physical, electronic, and social attacks. This type of testing should not only test electronic attacks by targeting web applications and network infrastructure but should include social and physical attacks that test staff, their adherence to policies, and building security measures in place.

In a red team exercise, a group of cybersecurity pros plays the role of attacker to test the effectiveness of your security program.

Why Conduct a Red Team Exercise?

Red Team exercises can be used to hone detective and protective controls as well as a security staff’s response skills. Your internal security team is the blue team, and is tasked with stopping adversary emulation of the red teamers in a simulated attack.

The  “Cost of a Data Breach report 2020” from IBM provides detailed quantitative data that shows that businesses who conduct Red Team exercises have reduced costs when a data breach occurs. The following year’s report lays out an updated list of the root causes of data breaches—all of which can be tested for and improved as part of a Red Team engagement—and identifies core test cases covered in a Red Team assessment.

Data showing that IR testing, Red Team testing, and employee training reduces the cost of data breaches. Source: “Cost of a Data Breach report 2020” from IBM page 42, figure 26.

Root causes of data breaches by threat vector. Source: “Cost of a Databreach report 2020” from IBM page 36, figure 21.

Focusing on maturing your prevention, detection, and response controls to protect against the most prevalent adversary tactic is an obviously wise decision. Red team exercises are a core element of increasing that maturity.

What Should a Red Team Exercise Provide?

At its base, make sure that red team techniques are modeled after real-life threats to your industry. You are having the assessment to test your ability to prevent, detect, and respond to real-world attacks. And, in the end, you need the assessment to provide tangible data for speaking to executives about your abilities to detect and eradicate a particular threat that concerns your business. You should know at which points in the attack chain your detective and preventive controls enable you to identify the threat, how long your team takes to eradicate the threat, and what blind spots need to be addressed going forward.

A well executed Red Team engagement is about more than just an attack simulation. The report after the assessment should be actionable, and provide data and metrics that are designed to inform executive decision making about future security spend. Along with a complete list of findings and remediation advice, a Red Team report should contain the following metrics:

• A “heat map” of your organization’s detection and protection maturity, mapped to individual attacker tactics, techniques, and procedures (TTPs)
• An analysis of which tools your organization uses, which TTPs each tool should catch, and any identified execution or coverage gaps
• Mean Time to Detection
• Mean Time to Remediation
• The eradication success rate

These metrics can help you decide whether it’s best to buy new products, invest in fine-tuning the products that you already have to improve their performance or invest in hiring or training for your team.

Am I Ready for Red Team Exercises?

In order to get the most value out of a Red Team exercise, your organization should meet a certain minimum level of maturity. You should have alerting, logging, and monitoring in place—either in-house or through an MSSP. You should have some idea of the TTPs that you should be able to detect in your environment. Vulnerability management and patching programs should also be in place. Full-scope Red Team engagements tend to be longer than traditional penetration testing engagements because of the different domains that are targeted, so budget may also be an important factor.

Let’s expand on this topic by using a boxing analogy. A Red Team exercise is intended to be a sort of sparring exercise between the Blue Team and the Red Team, whereas a live incident would be more like an actual fight. The purpose of sparring (Red Teams) is to practice and drill for the real event, to do so repeatedly and develop “muscle memory” so that dealing with a real threat becomes second nature. That said, when a novice walks into a gym and says they’d like to learn how to box, they don’t get thrown in the ring to spar with a champ on the first day. It’s important that they learn the basics first: conditioning and knowing how to punch, block, and move. A mastery of the basics is required to be successful in the ring, and Red Teaming is no different.

What Can I Do if I Don’t Think I’m Ready Yet, or if I Don’t Have the Budget for a Full-Scope Red Team Engagement?

A Red Team exercise is simply one type of adversarial simulation exercise, and it certainly isn’t the only thing you can do to improve your organization’s security posture. Any phase of a Red Team exercise can be broken out and conducted on its own.

Collaborative adversarial simulation exercises (sometimes referred to as Purple Team exercises) can fill many of these gaps. These exercises can be as simple as agreeing on a set of TTPs to be tested and having a team execute attack scenarios around each TTP as a unit test.

In these instances, Red Teams often work alongside Blue Teams and explain each attack, how it works, and what the implications are before execution. Notes about whether the Blue Team has detected or prevented the scenarios can be turned into a heat-map that outlines the organization’s detection and protection maturity, mapped to a standard framework such as MITRE ATT&CK, to give a quick visual representation of the current state of the program.

These tests are highly repeatable, can be executed quickly, and can provide immediate feedback to improve an organization’s detection and protection posture.

Similarly, if you have concerns about having a team attempt to break into your facilities, you can scope a physical assessment that instead consists of a walk-through and evaluation of the physical security controls and policies that are in place.

If your intention is to baseline your exposure to help focus future efforts, an external and/or internal network penetration test will give you an asset inventory and actionable steps that will immediately decrease your areas of highest risk.

The key is that you should never feel forced to choose a full-scope Red Team engagement just because it maps neatly to a specific offering from your vendor. Your vendors should adapt and work with you to provide value to your organization that fits with both your current security program’s maturity and your budget.

Learn about Security Compass Advisory’s red teaming methodology. Then, contact us today to learn how our Red Team Services can help you improve your ability to defend against, and respond to, attacks that put your operations, data, and reputation at risk.

The post What Is a Red Team Exercise & Why Should You Conduct One? appeared first on Security Compass.

Security Compass Continues to Successfully Execute on it’s Business Continuity Plan.

On March 13th Security Compass asked employees to work from home, and this week officially closed all global offices.  I am happy to report that we were fully prepared to have all our employees work remotely and have therefore continued operations without disruption. We are supporting our products and delivering our services with the same outstanding attention to customer experience that you have come to expect.

Rohit Sethi,

CEO

———————————————————————————————————————————-

March 14, 2020

To our customers, prospects, partners, suppliers, and communities:

The spread of Covid-19 is having an unprecedented impact on the way we live and work. At Security Compass we take our responsibility to all stakeholders seriously. Our executive committee is monitoring developments related to the virus and communicating regularly with our employees and our broader group of stakeholders.

Our primary goal in formulating a Covid-19 response plan is to contribute to “flattening the curve” by increasing social distance. We believe this is important not just for our collective safety, but also that of the greater community. At the same time, we are committed to maintaining the excellent level of service our customers have come to expect, and need from us no matter the circumstances.

To these ends, we have asked our employees and contractors to work from home, restrict non-essential business travel and report any potential exposure to the virus. Our eLearning and SD Elements customers will continue to be supported largely without change.

Our consulting customers will continue to receive remote services as planned. To preserve our policy of social distancing, we are restricting on-site consulting work and in-person sales/account management visits.  For consulting customers with planned on-site work, your engagement owner will reach out to you to coordinate an alternative plan. We will help you mitigate the impact of this restriction, for example, by performing security testing work remotely where technically possible.  We will work collaboratively to ensure you can fulfill your relevant security and compliance obligations. All of our employees are equipped with remote working and teleconference capabilities and are fully committed to continue serving you.

If you have any questions or concerns do not hesitate to reach out to your Security Compass contacts.

I’m confident that through collaboration, innovation, and caring for each other, we will overcome this challenge. I wish the best for you and your families. Stay informed, and stay safe.

Rohit Sethi,

CEO

About Security Compass
Security Compass, a leading provider of cybersecurity solutions, enables organizations to shift left and build secure applications by design, integrated directly with existing DevSecOps tools and workflows. Its flagship product, SD Elements, allows organizations to balance the need to accelerate software time-to-market while managing risk by automating significant portions of proactive manual processes for security and compliance. SD Elements is the world’s first Balanced Development Automation platform. Security Compass is the trusted solution provider to leading financial and technology organizations, the U.S. Department of Defense, government agencies, and renowned global brands across multiple industries. The company is headquartered in Toronto, with offices in the U.S. and India. For more information, please visit https://www.securitycompass.com/

The post A Message From Our CEO appeared first on Security Compass.