I’ve been in cybersecurity for 25+ years, and the most popular question I get is my recommendation for how people can get started.

Here are six things that have impacted my career and helped me grow as a security person and a human being.

1. Get a solid understanding of systems and networks. Systems and networks are the foundation for everything we do in security. If you want to be better at security, you must have a foundation in TCP/IP. Both on the theoretical side and on the application side. The easiest way to get this experience is to become a systems administrator. The lessons I learned as a sysadmin allow me to speak about things in security, such as DNS, that I would only be talking about theory if I hadn’t ever wrestled with. Since I’ve had my hands on a DNS server and configured zones, I truly understand the security challenges of DNS.
2. If you don’t have Virtual Box installed on your laptop, do it now. Virtual machines are your friend. You can configure different machines (Windows, Linux, etc.) with virtualization and connect them. You can practice with the best security distributions (Kali, Web Security Dojo, etc.) without getting arrested! Learn to use Virtual Box (open source, by the way) and build VMs to test things and learn how they work. Have a system administrator mindset.
3. Read like crazy. In the security business, things are always changing. Whether new technologies (zero trust is the hot thing now) or new techniques, this industry is not stagnant. To get ahead in any industry, you must continue to grow and learn. Become an avid reader, and learn from the books you read. Even though college is over, take notes about the things that catch you in the book, and act upon them. Do not think you must limit yourself to non-fiction. Sprinkle fiction in as well to expand your mind.
4. Learn to code in a minimum of one language. Code is the foundation of everything in security. Learn at least one object-oriented programming language proficiently. You’ll be amazed at how you can apply the knowledge of a single language to any other language.
5. Take advantage of the training resources available on the Internet. There are many free security courses and training opportunities from Universities (Stanford and MIT), YouTube, where all the local conferences are archived, and Codecademy. Take advantage of the content that is out there and learn from it. Pick a specific topic and focus on it for a month. If you know nothing about Javascript, then learn it. You do not need the proficiency of someone who builds web applications daily, but knowledge can be applied when the situation arises.
6. Network, and not in a cheesy walk around and hand out business cards way. Make friends in the security industry. Do this on Twitter or Mastadon. Do not use Twitter as a news feed. Respond to security people and get into conversations. The worst thing that happens is that they ignore you. Go to conferences, and don’t just stand in the back of the room like you are at a middle school dance. Introduce yourself to people, talk before the sessions start, and make yourself a part of the community. You’ll benefit greatly from the relationships you establish with real security people.

On a recent podcast episode of the Security Table, the gang and I discussed the Lastpass breach and the impact of security products as utilities. We spent time unpacking the concept of a security utility.

A security utility is like a municipal utility, say, your water service. You have expectations of your water service. You expect that water is available on the line as long as you regularly pay your bill. When you lift the faucet or turn on the washing machine, you expect water to come out. A security utility is much the same — a security service that you rely upon to enhance your security stance and one that you expect to always work. You can also think of it as a product or service that, if it fails, results in the breakdown of your approach to securing your digital footprints.

This discussion caused me to think deeper about the expectations of a security utility. It came down to three primary categories:

1. Secure by default and in every situation.
   • When purchasing a security utility, expect that its creators have thought about security from every angle and in every situation. In the example of a password manager, expect that passwords will be securely stored in the cloud so that only the owner can access the passwords. Secured in such a way that the provider cannot even access the passwords.
2. Simple to install/administer.
   • Security utility should be simple. Of course, simple is always more secure than complex, but in this case, with security utility, end-users don’t want to spend time “figuring the service out.” This leads to the final category.
3. Always works without any thought.
   • Security utility should always work. Consumers don’t want to think about how a security product or service will work; they expect it will always work. That is the beauty of the solution — you don’t have to think about it; it is always there, always protecting you.

All of this to say, I had a personal experience where utility, and to some degree security utility, came into play. I built my home Wifi network using Ubiquiti gear a few years ago. I had a Wireless Controller, six access points distributed around the property, and a PoE switch that fed the access points. What I also had was a significant amount of complexity. I added a 48-port PoE switch to work in additional wired connections, which broke the setup. The network was down a few times over a month, and I spent hours troubleshooting a phantom problem where devices would appear and disappear. When they disappeared, they stopped functioning but would reappear minutes later as if nothing had happened.

I decided to adopt a utility approach, and I ripped out all this complex gear and replaced it with a mesh Wifi solution. Instead of multiple layers of network and security devices, my Wifi is now the gateway to my home network. I now have a solution that is secure by default, simple to work with, and always works, with no troubleshooting by me.

As folks who build products embrace the idea of security utility, anything you build should strive to become a security utility, easy to use by those who gain value from it, with minimum effort required to make it all work.

I got into security almost by accident. After graduating from university, my wife and I moved to Northern Virginia in 1997. There, I attended a job fair at a hotel. Standing in line to meet with a large government contractor, I investigated a room to my left, off the hallway. I saw a guy sitting, typing on a laptop, and talking to nobody. I thought, “Huh, this line will be here when I get back; let me see what this guy is up to.” I walked up to him and struck up a conversation. And just like that, I met Mike Weidner.

During the conversation, Mike explained how they were looking for a system administrator, and I began the interview process then and there. After some follow-on interviews at their offices at Boone Blvd in Tysons Corner, Virginia, I was offered the job. Keep in mind that I had no idea what a “security” company did, but there I was.

The next few years were incredible, as I was transformed from a system administrator into a security engineer. I stood on the shoulders of giants in the industry, learning from Marv Schaefer, Gary Grossman, Chuck Pfleeger, Victoria Thompson, Stan Wisseman, Bill Wilson, and many others. They taught me the true meaning of threats and how threats manifest in different pieces of a system. I worked alongside people who have grown into giants in the industry— Doug Landoll, Diann Carpenter, Jeff Williams, and Klayton Monroe. They pushed me to keep up and learn everything thrown my way.

My first big takeaway from my Arca experience is the importance of pouring into the next generation. I look for opportunities to mentor newer security folks every chance I get. I’ve made this a priority since my days at Arca. It’s not like I came up with this on my own — I’ve reflected on what I was taught by all the Arca industry giants — pour into others, as the return is great.

As the Internet bubble was in full swing, Arca was acquired not once but twice. The first acquisition didn’t stick, as the acquiring company had some issues, and we landed as the new security consulting arm of Exodus Communications. Exodus was the company that everyone used, but most had no idea. Exodus, at its peak, had 44 data centers worldwide, and three out of every four clicks on the Internet went through our data centers.

I started as a Senior Security Consultant and migrated into Incident Response. Exodus brought together a group of ex-FBI agents and people like me that had been using computers for decades. We investigated many major breaches and worked on industry-wide security events under the guise of the Cyber Attack Tiger Team or CATT. When the Internet bubble burst, so did Exodus, and I was back on the move.

I had a few jobs between Arca and Exodus, all without leaving. My takeaway from this time was to reinvent yourself often. I went from consulting to Incident Response and learned a whole new discipline. I leaned into all the Exodus CATT team members could teach me — learning from trained investigators from the FBI and other Intelligence agencies. Reinvent and never stop learning. Our field is so large we must all continue to learn new things.

After Exodus, I had a brief and uneventful stint at a Government Contractor. From there, I landed at Cisco and worked on Common Criteria and FIPS 140 certifications for five years. After leaving certifications and joining an inward-facing product security team, I was challenged to bring threat modeling to the whole engineering organization. I dove deep into threat modeling, grasping how to perform it. I was the Chief Security Advocate at Cisco for five years, and one of the things I did there was work with Erick Lee to define requirements for Cisco’s threat modeling tool (which Erick did all the coding for). Afterward, I worked toward distributing the tool to engineers across the company. We saw success in our efforts as threat modeling became a prominent piece of Cisco’s Secure Development Lifecycle (CSDL).

After a few years, I left Cisco to start Security Journey. First, I built a product that teaches developers and product-adjacent people the foundational, intermediate, and advanced facets of application security. Then, I led Security Journey to an exit in 2022. (If you are wondering, in my next chapter as CEO of Kerr Ventures, I’ll split my time between startup investing/advising, consulting, and incubating my next idea(s).) I’ve written all my learnings from Security Journey in a series of yearly posts that you’ll find on the Kerr Secure Blog.

When I ponder all the different job functions and opportunities that I had, I realize that while the technical side of security is important, it’s the easier part of what I’ve accomplished. The soft skills of leadership are things that I developed by watching excellent leaders lead. From my managers at Arca to Tom Sweeney at Cisco, I learned how to lead by watching others lead well. I’ll never forget my favorite Tom Sweeney quote — “Judge yourself not by the number of people you manage, but by how many managers you create.” This embodied Tom’s philosophy — pour into people.

Back on the security side, as I think about everything I’ve seen on my personal security journey, it feels like we’ve come so far, yet we have so much further. In my time, we’ve gone from a client-server desktop-focused world to fully networked, containerized, and cloud-native delivery. The technology we rely upon has revolutionized how we deliver IT and applications, yet we still have threats. The threat landscape has changed over time as new attackers enter the scene, new attack scenarios are dreamed up and implemented, and the number of interconnected devices has exponentially grown. At the end of the day, it still comes back to threats. The threats are consistent across the decades, and the need to understand them and mitigate them continues to be a priority.

In my career around application security, I’ve watched the industry go from waterfall to Agile to DevOps. When I ponder the application security impacts, we are doing the same activities with DevOps that we did with waterfall at a more increased pace. Threat modeling is important in all methodologies, just like SAST, DAST, SCA, CVA, and RASP should be incorporated into every application security program today. While some things change, some things stay the same.

I often wondered in the early days of my career if we would run out of threats and put ourselves out of jobs by solving all the security challenges. I thought there was a chance in those early days, but as the years went by, I understood that I’d retire from this industry someday, and the threats would still exist. They would look different than when I started, but there will be plenty of room for engineers to continue to tackle the newest threats that impact the human beings of the Internet.

We still need more people in our industry. We can argue about how many people we need, but we can all agree that we need more people. I don’t see myself moving away from the world of security. I dream of being like my friend Brook Schoenfield when I grow up, continuing to share my knowledge and experience across our industry. Brook calls himself the “Elder Statesman of AppSec.” Someday, I hope to be invited to that group. I feel like I still have much more to learn.

After the release of the Threat Modeling Manifesto, which was a gigantic success, both as a collaborative working group amongst fifteen Threat Modeling experts, and as the seminal work defining the essence of threat modeling, Marc French, Adam Shostack, and I talked about what we could do next to improve the world of application security.

We identified a need for a document that helps people new to Security Champions build a program. We created a new working group to create similar work to the TM Manifesto for Security Champions.

We waffled between creating a Security Champion Manifesto, a framework, a book, or a series of blog posts. Ultimately, the Champion group lost steam due to circumstances that took various team members away from the project, including me, at the time.

From the beginning of the effort, I had envisioned that the output should be a framework and a maturity model for Champion programs. My vision was a document that would capture various maturity levels across the most important pillars of a program.

My thoughts crystallized in various talks I delivered in 2022. I started at RSA with a talk entitled “Elite Security Champions Build Strong Security Culture in a DevSecOps World,” which a recording can be found on Youtube: https://youtu.be/9gVM93a1H1I. I delivered a refined version for the ISC2 Security Congress, where I fleshed out the initial categories of the Security Champion Framework.

The framework categories are based on my experience running a large-scale Champion program at Cisco from 2011-2016 and consulting and advising various Champions programs as a consultant from 2017-2022. I’ve collected feedback from other practitioners and program builders. I want the framework to be larger than my experience and capture the experience of experts from around the globe.

Using the words of the framework itself, “The Security Champion framework exists as a measuring stick and a roadmap. As a measuring stick, the framework allows leaders to measure how well their champions program performs. As a roadmap, the leader can use the measurements as input and build a plan to improve their program by applying updates towards a higher framework level.”

Five high-level areas divide the framework, with one to four sub-areas within each area.

Area	Description
Planning	Planning includes the activities needed to scope and build a strategy.
People	People include recruiting, retaining, capturing commitment, and onboarding new champions.
Marketing	Marketing includes the branding of the program and communication plans.
Execution	Execution includes the program pillars, coaching, education, and globalization efforts.
Measurement	Measurement includes metrics for demonstrating the value generated by the program.

The Framework is released as CC-4.0-Sharealike. We are accepting PRs as feedback and additions to the framework. Please dive deeply into the framework and put it into use, and let us know of anything we missed: https://github.com/edgeroute/security-champion-framework

Dear Security Journey,

As I prepare to depart the company, I’ve had time to reflect on what Security Journey means and why Deb and I built it the way we did. We started in 2016 with me as a traveling security consultant and moved into a product company with eighty customers before the acquisition.

We started Security Journey to change how the industry approaches security training. We focused on providing an experience that changes security culture rather than checking a training box. We built something that our customers needed, and we based it on real-world experience.

Security Journey was born from all I learned at Cisco about creating an excellent educational experience. It all starts with the content, whether video or hands-on. The content must drive everything you do now and into the future. The content’s quality sets Security Journey apart from the competition. Of course, the platform is essential, as the administrators need features to execute their programs. Still, the content makes Security Journey stand apart, and each learning unit represents a small step toward changing security culture.

Our approach has been to create the most excellent technical content and boil topics down to the most critical pieces a developer needs to know. So I am excited to see where the content engine goes in the future.

Fight for our Customers; from Customer Success to Sales to Product to Marketing to Engineering, keep the Customer at the center of everything you do. Partner with them, learn from them, and do what’s right for them.

In my mind, I’ve completed the task I set out to achieve: build a product that changes security culture. Now I leave the future to you as Security Journey team members. Take this product further than I ever imagined; use your creativity, knowledge, and skills to continue to revolutionize the industry. I have faith in you. I’ll be cheering you on from a distance.

As a Board Member, I’m available to do anything I can to help you succeed. So feel free to reach out if there is anything that I can do to help you achieve your mission.

Thanks,
Chris Romeo
Co-Founder of Security Journey

Over October 2022, for NCSAM, I shared thirty-one random AppSec thoughts. For some of these thoughts, I’ve pointed to other writings I’ve prepared covering the topics more in-depth.

1. Shift left and shift right = Secure Development Lifecycle. What’s old is new again.
   • Read more — Secure Development Lifecycle: The essential guide to safe software pipelines
2. With all the attention on API security, we often overlook the OWASP API Security Top Ten.
   • Read more — OWASP API Security Top 10: Get your dev team up to speed.
3. The OWASP Proactive Controls is the answer to how to fix/avoid the issues of the OWASP Top Ten.
   • Read more — OWASP Proactive Controls: the answer to the OWASP Top Ten
4. #ThreatModeling is analyzing representations of a system, to uncover the security and privacy challenges that exist.
   • Read more — The best threat modeling representation
5. Why do we have so many 4-letter acronyms in #AppSec? SAST, DAST, IAST, and RASP, oh my!
6. Security culture is measured by what your developers do with a security problem when nobody is looking.
   • Read more — 6 ways to develop a security culture from top to bottom
7. Security champions are a force multiplier for your security team.
   • Read more — Information security needs community: 6 ways to build up your teams
8. Imagine a future where all developers are security enlightened.
9. Everyone is a security person — no matter your functional role within the organization, you own a piece of the security solution.
10. Security culture eats strategy for breakfast.
11. People, process, tools, and GOVERNANCE. Governance is the piece that everyone always forgets.
12. Security should never be a gatekeeper — security should open doors, not shut them.
    • Read more — Why developers dislike security—and what you can do about it
13. Regardless of how much effort you put into breaking, security is no better until the builders engage.
14. OWASP is a treasure trove of security resources.
    • Read more — How to do application security on a budget
15. Break the build for vulnerable open source and third-party, but provide a filtering mechanism to allow builds to progress when there is no known fix.
16. Shift {left, right, outwards} – just start.
17. The Sec in #DevOps is silent.
18. GitHub is a terrible place to store secrets.
19. Teach the developers the underlying principles of the tools, and then watch how the tools magnify #AppSec.
20. Security requires the ability to sell and market. The best security people can explain their idea well, share the value prop, and communicate.
21. Developers take pride in their craft — they want to create more secure code — you must show them the way.
22. Pipelines are the best way to represent a #DevSecOps build pipeline.
23. Developers must understand all the component pieces of the build pipeline. Developers are smart — they’ll provide feedback on those pieces and help tune the tools.
24. Launching a new security tool does not mean we enable every policy — increasing the fidelity of the security tool results in developer buy-in.
25. Security people must learn how to code. The resources on the Internet are vast, and the excuses for why you don’t need to code are few.
26. The DevSecOps Maturity Model (DSOMM) is an assessment tool for your DevSecOps and a builder of roadmaps.
27. As a security professional, drop the no; try “yes, if.” Be a partner and not a roadblock.
28. Threat modeling uncovers design-related issues, and the best threat modeling tool is the human brain.
29. Guard rails are a better strategy than roadblocks. Provide limits, and encourage creativity within the boundaries.
30. At the end of the day, #AppSec is a people-based solution, with support from the process and the tools.
31. We have too many data streams in an #AppSec program; look for tools to correlate and consolidate the streams into developer-usable results.

The OWASP Proactive Controls is one of the best-kept secrets of the OWASP universe. Everyone knows the OWASP Top Ten as the top application security risks, updated every few years. The OWASP Proactive Controls is the answer to the OWASP Top Ten. Proactive Controls is a catalog of available security controls that counter one or many of the top ten.

For example, Injection is a famous top ten item, having lived within the OWASP Top Ten since its inception. One still prevalent category of Injection is SQL Injection. The counter to SQL injection from the proactive controls is “C3: Secure Database Access” and other controls. C3 prescribes secure queries, configuration, authentication, and communication for database transactions. These techniques work together to prevent data loss due to SQL Injection.

Here is a map between the OWASP Top Ten 2021 and the Proactive Controls updated in 2018.

OWASP Top Ten 2021	Proactive Controls 2018
A01:2021-Broken Access Control	C7: Enforce Access Controls
A02:2021-Cryptographic Failures	C2: Leverage Security Frameworks and Libraries C8: Protect Data Everywhere
A03:2021-Injection	C3: Secure Database Access C4: Encode and Escape Data C5: Validate All Inputs
A04:2021-Insecure Design	No mapping
A05:2021-Security Misconfiguration	No mapping
A06:2021-Vulnerable and Outdated Components	C2: Leverage Security Frameworks and Libraries
A07:2021-Identification and Authentication Failures	C6: Implement Digital Identity
A08:2021-Software and Data Integrity Failures	C2: Leverage Security Frameworks and Libraries C4: Encode and Escape Data C5: Validate All Inputs
A09:2021-Security Logging and Monitoring Failures	C9: Implement Security Logging and Monitoring C10: Handle all Errors and Exceptions
A10:2021-Server-Side Request Forgery	C5: Validate All Inputs

Let’s explore each of the OWASP Top Ten, discussing how the pieces of the Proactive Controls mitigate the defined application security risk.

A01 Broken Access Control

Broken Access Control is when an application does not correctly implement a policy that controls what objects a given subject can access within the application. An object is a resource defined in terms of attributes it possesses, operations it performs or are performed on it, and its relationship with other objects. A subject is an individual, process, or device that causes information to flow among objects or change the system state. The access control or authorization policy mediates what subjects can access which objects. In the worst cases, authorization is forgotten and never implemented.

The Proactive Controls offer C7: Enforce Access Controls, which describes Discretionary, Mandatory, Role-based, and Attribute-based access control strategies. The document also provides a solid list of design principles for access control.

Action: Attribute-based access control (ABAC) is the most mature and capable of all the strategies. Use ABAC as your template, and apply the access control design principles.

A02 Cryptographic Failures

Cryptographic failures are breakdowns in the use of cryptography within an application, stemming from the use of broken or risky crypto algorithms, hard-coded (default) passwords, or insufficient entropy (randomness). A broken or risky crypto algorithm is one that has a coding flaw within the implementation of the algorithm that weakens the resulting encryption. A risky crypto algorithm may be one that was created years ago, and the speed of modern computing has caught up with the algorithm, making it possible to be broken using modern computing power. A hard-coded or default password is a single password, added to the source code, and deployed to wherever the application is executing. With a default password, if attackers learn of the password, they are able to access all running instances of the application. Insufficient entropy is when crypto algorithms do not have enough randomness as input into the algorithm, resulting in an encrypted output that could be weaker than intended.

Proactive Controls offer two solutions for cryptographic failures: C2: Leverage Security Frameworks and Libraries
and C8: Protect Data Everywhere. C2 prescribes the use of known good security frameworks and libraries. The same holds true for the source of cryptographic algorithms and implementations. Find a reliable, trusted source for your cryptographic functions, and rely upon that implementation to deliver your application’s cryptographic needs. C8 calls for data protection everywhere, in transit between your application and users and while resting in a database.

Action: Find a solid, trusted crypto library for your application and encrypt sensitive data in transit and at rest.

A03 Injection

An injection is when input not validated properly is sent to a command interpreter. The input is interpreted as a command, processed, and performs an action at the attacker’s control. The injection-style attacks come in many flavors, from the most popular SQL injection to command, LDAP, and ORM.

Proactive Controls has a plethora of options to deal with injection. C3: Secure Database Access was tailor-made to counter SQL injection. C3 includes securing the queries with prepared statements and using object-relational mapping libraries to isolate the raw creation of SQL queries. Secure configuration, authentication, and communication protect the database server and the database’s connection parameters. C4: Encode and Escape Data protects any data that is reflected back to the client, and C5: Validate All Inputs ensures that the input that comes inbound is validated using various rules.

Action: Validate all input, and avoid exposing any input directly to an interpreter.

A04 Insecure Design

An insecure design focuses on the design and architectural flaws. Many future vulnerabilities can be prevented by thinking about and designing for security earlier in the software development life cycle (SDLC).

There is no specific mapping from the Proactive Controls for Insecure Design. The Top Ten calls for more threat modeling, secure design patterns, and reference architectures. Threat modeling analyzes a system representation to mitigate security and privacy issues early in the life cycle. Secure design patterns and reference architectures provide a positive, secure pattern that developers can use to build new features.

Action: Threat model everything in sight and use secure design patterns and reference architectures as the foundation for anything new.

A05 Security Misconfiguration

Security misconfiguration is when an important step to secure an application or system is skipped intentionally or forgotten. Examples of security misconfiguration include missing appropriate security hardening, unnecessary features being enabled or installed, default accounts being enabled and unchanged, error handling bleeding information, disabling security features, or setting application frameworks to insecure settings.

There is no specific mapping from the Proactive Controls for Security Misconfiguration. The Top Ten calls for a repeatable hardening procedure as the foundation of how to counter security misconfiguration. C2: Leveraging Security Frameworks and Libraries could result in choosing frameworks with secure default configurations, which would counter various security misconfigurations.

Action: Harden everything within your environment, and look for frameworks with secure defaults.

A06 Vulnerable and Outdated Components

The world of software is made up of various libraries and frameworks. Developers write only a small amount of custom code, relying upon these open-source components to deliver the necessary functionality. Vulnerable and outdated components are older versions of those libraries and frameworks with known security vulnerabilities.

An application could have vulnerable and outdated components due to a lack of updating dependencies. A component, in this case, was added at some point in the past, and the developers do not have a mechanism to check for security problems and update their software components. Sometimes developers unwittingly download parts that come built-in with known security issues.

The Proactive Controls doesn’t have direct instructions to update dependencies often; there is a close match with C2: Leverage Security Frameworks and Libraries. The critical thing to remember is that when you use frameworks and libraries, you must instill a plan to check for known vulnerabilities and update those dependencies. Dependencies link to other dependencies, which results in an application relying upon thousands of packages with limited visibility to the developer of all those packages. Libraries and frameworks age like milk — they quickly curdle and need to be replaced with newer versions.

Action: If you use a framework or library, check for known vulns and update often!

A07 Identification and Authentication Failures

Identification and authentication failures occur when an application cannot correctly resolve the subject attempting to gain access to an information service or properly verify the proof presented as validation of the entity. This issue manifests as a lack of MFA, allowing brute force-style attacks, exposing session identifiers, and allowing weak or default passwords.

The Proactive Controls prescribes C6: Implement Digital Identity, which ties into the advanced authentication requirements presented in NIST 800-63b. Guidance is also provided about cookies, tokens, and the use of JWT.

Action: Implement the highest level you can support from NIST 800-63b.

A08 Software and Data Integrity Failures

Software and data integrity failures include issues that do not protect against integrity failures in software creation and runtime data exchange between entities. One example of a failure involves using untrusted software in a build pipeline to generate a software release. Another example is insecure deserialization, where an application receives an object from another entity and does not properly validate that object, resulting in an attack being loosed upon the application that received the object.

Use the Proactive Controls for validation and encoding (C4: Encode and Escape Data and C5: Validate All Inputs) to prevent insecure deserialization. Properly encode output and use JSON and other object-oriented binary styles. To protect the inputs in a build pipeline, rely upon C2: Leverage Security Frameworks and Libraries to ensure that you use the best possible components available, and enact methods to ensure that you have the released version of the software and not something that has been tampered with by an attacker.

Action: Enhance integrity by validating the software you use, and avoid serialization; instead, use JSON as a text format for inter-system data exchange.

A09 Security Logging and Monitoring Failures

Logging is storing a protected audit trail that allows an operator to reconstruct the actions of any subject or object that performs an action or has an action performed against it. Monitoring is reviewing security events generated by a system to detect if an attack has occurred or is currently occurring. A failure is when either of these actions is not performed correctly.

The Proactive Controls provide C9: Implement Security Logging and Monitoring, with direct guidance on tips and tricks for successful logging, avoiding other potential pitfalls that could result in attack conditions in the logging system. C10: Handling all Errors and Exceptions provides additional context for extending applications to reflect error conditions. The application has visibility into your logging and monitoring constructs.

Action: Just log and monitor; it may be near the bottom of the list, but it is the only way to know what steps have been performed against your system.

A10 Server Side Request Forgery (SSRF)

A Server Side Request Forgery (SSRF) is when an application is used as a proxy to access local or internal resources, bypassing the security controls that protect against external access.

While the Proactive Controls do not specifically address SSRF, C5: Validate All Inputs includes the validation of URL parameters, which are the root of most SSRF vulnerabilities.

Action: Validate any URLs allowed as input, and filter out any SSRF conditions.

Conclusion

While the current OWASP Proactive Controls do not match up perfectly with the OWASP Top Ten for 2021, they do a fair job of advising on controls to add to your applications to mitigate the dangers the Top Ten describes.

Ironically, the only Proactive Control that does not line up with one of the OWASP Top Ten 2021 items is C1: Define Security Requirements. C1 describes security requirements, points to the OWASP Application Security Verification Standard (ASVS) as a source, and describes a path for implementing security requirements. Proper security requirements can assist in limiting the blast radius of the OWASP Top Ten. Shifting left is a real thing, marketing term or not, and considering requirements early in the process of building something new lessens the impact of the OWASP Top Ten.

References

• OWASP Top Ten
• OWASP Proactive Controls
• OWASP ASVS
• OWASP Cheat Sheet Series
• OWASP MASVS