Credit: Daniel Cheung @ Unsplash
After working in the application security consulting industry for nearly two decades and helping to solve my clients’ most difficult challenges, it was time to put what I used to tell others into practice. These are my lessons from the first 100 days. I’ve created security teams, bug bounty programs, set up tooling strategies, hiring plans, and more. I thought I’d hit the ground running and start making an impact on day 1, or at least day 99, while I made some impact early I had a lot to learn. As I passed my 100th day I learned so much about what makes a successful product and a successful product security team. In this article I’ll walk you through the successes, challenges, and failures I’ve faced in my transition from seasoned security vendor to Senior Director of Product Security at Highspot .
Read more >>
Credit: Patrick Tomasso @ Unsplash
The purpose of this document is to outline an application security strategy and roadmap for AWS Cloud SaaS applications, covering both application security concerns as well as AWS specific infrastructure. This is a checklist style article to help start conversations and give you information to perform further research. I’ve referenced other white papers and further reading available for more information throughout. An effective application security program will reduce security risk associated with code development while keeping disruption to the normal SDLC processes to a minimum. Ideally, this is done in an environment that fosters cooperation and transparency between AppSec professionals and the development team as a whole. If the entirety of the team is on the same page in regard to application security goals, and the maturity journey to get there, then the security team can operate as a service organization whose goal is enablement, rather than as a policing organization whose goal is governance.Purpose
Application Security
Read more >>
Credit: Joe Basirico
Last week I published a post introducing three important phases of AppSec Engineering: Awareness, Enablement, and Enforcement. Over the next three posts I will dive into each of these topics to share best practices and guidelines you can roll out to optimize your security engineering practice. In my experience, the best AppSec programs start with AppSec awareness training. The goal is to provide your product team with enough information to know when they need security involvement. That’s a broad statement, so let’s break it down.This is part of a series
Read more >>
Credit: Joe Basirico
In order for an AppSec team to collaborate effectively with development teams they should think in three phases: Awareness, Enablement, and Enforcement. This month I’ll be dedicating an article to each. The focus of these articles will be on the critically important area of application security, focused on the roles involved in building software: developers (DevOps), testers, and architects.This is part of a series
Read more >>
Credit: Joe Basirico & Rob Curran
I recently talked with a CISO friend of mine who was struggling to scale his security team. He has fewer than 10 security people on his team to support an organization with over 500 developers and 2000 employees. Responding to all of the requests which include: development best practices, legal and compliance, security awareness, IT security, trying to organize his team to perform the scanning, testing, reviews and more left him under water and stressed out!
Read more >>
Credit: Pexels
In my last blog post, I wrote about what an application security program is and why it matters. In this post, I’ll cover what it takes to build and scale an effective application security program. I’ve seen many different ways that a well-intentioned program can fail to meet its objectives. While there may be many ways to fail, there are just a few key characteristics that lead to success. The program must be:
Read more >>
Credit: Pexels
In the late 1990s I worked on the security team for Internet Explorer. In fact, I was the first hire that Microsoft made in response to an influx of browser-based security vulnerabilities. I got to see what it looks like when a development team is bombarded by security problems that are serious enough to require a response and yet there’s no process to handle it. In the early days we would get at least one new vulnerability each week. The cost to respond was over one million dollars - per vulnerability! Every time it happened, we had to stop development, understand the problem, understand the fix, test the fix, and then release to customers. A team of over four hundred developers and testers was stopped in their tracks on a regular basis. You can only do that for so long before you realize that something has to change. On the Internet Explorer team we developed a new set of processes, skills, and tooling that allowed us to rise to the challenge. We did what we had to do to solve the problem while under a constant barrage of enemy fire. In the end, we built and scaled an application security program that worked not only for Internet Explorer but for the rest of Microsoft product development as well. Today that process is called the Microsoft SDL and Trustworthy Computing.
Read more >>
Credit: Kroll Historical Maps
My favorite thing about my career in security consulting has been the constant opportunity to learn new topics. Security weaves itself through every aspect of software, and software is everywhere. The phone in your pocket, the bluetooth chip in your headphones, your automobile, and the SCADA systems you rely upon every day execute millions of lines of code on your behalf. The idea that each of those systems gives me the opportunity to gain new knowledge is truly exciting. It can also be daunting when there is always so much to learn.
Read more >>
Credit: Jay Heike @ Unsplash
Firefighters are heroes. They rush into burning buildings to save our families and heirlooms from disaster. They are there in the middle of the storm to help. Building Inspectors are bureaucrats. They tell us how to safely build and remodel while mitigating unforeseen threats that may never come. But who has saved more lives and property? It’s difficult to determine how many disasters have been averted by building codes or by the recommendations and requirements from building inspectors, but I suspect a lot more disasters are averted through their careful building plans, processes, and procedures than by firefighters responding to a fire.
Read more >>
A friend of mine just left the world of consulting. I asked him for the biggest change in his thinking, he said: Something is going to go wrong. It’s not a matter of if, it’s when. When that bad thing goes wrong everything hinges on how you detect and respond to it. As consultants so much of our job is focused on reducing risk for our clients, but that’s all we can do. We reduce the risk, we can’t take it all away. That means that no matter what we do, or what our clients do, there will always be some risk. On a long enough timescale there is guaranteed to be a breach, data loss, a denial of service, or some other security incident.
Read more >>
I used to think I’d like to be a CISO. Now that I’ve spent the past few years speaking with CISOs, I’m not so sure I’d want the job. CISOs have targets on their backs, they hold our data in their hands and I, for one, am thankful for what they do. I’m convinced that the CISO job is one of the hardest, most thankless, and most stressful jobs on the planet. I know there are worse jobs out there - bomb squad, for instance. But there aren’t many.
Read more >>
… or not enough, but you certainly don’t have it right. Security takes commitment, but it’s not as simple as all or nothing. Knowing how much to commit for your level of risk tolerance is critical. The first thing you need to do when improving your security program is set honest goals about what you want to achieve. Ideal security investment means, do what is necessary and nothing more. Every dollar you spend to secure something that isn’t going to be attacked is a dollar that isn’t used to lead the market, build new features, or sell and market your solutions.
Read more >>
In my last post , I talked about the fact that none of us knows how to solve the problem of cybersecurity. It’s a tautology, so it shouldn’t be surprising. If we knew how to solve the problem, the problem would be solved. Therefore we don’t know how to solve the problem. But it is surprising, and so it feels like a ‘hard truth’ rather than ‘the truth’. When confronted with a long-standing problem (like cybersecurity), it is typical to assume that if we had more will, more resources, more intelligence, or perhaps more of all of the above, we could solve the problem. We don’t stop to think about the fact that if what we are doing isn’t working, doing more of that same thing probably isn’t going to change the situation. It can be tough to admit when we don’t know what we are doing.
Read more >>
Earlier this year I listened to Sabu talk. Sabu the hacker. The same guy who was the brains behind Anonymous, who knocked down email servers in Iran, who attacked DNS servers in China, who participated in the cyber fight during the Arab Spring. The same Sabu who turned on his fellow hackers, putting them behind bars in order to reduce his own prison sentence. This is a guy who has been on the dark side and come out to tell us about it. Can we trust him? Maybe not. But when he tells his stories about the dark side of the web he has credibility.
Read more >>
Security enforcement is the traditional way of thinking about security, in which security teams are set as a gate to pass before software is allowed to be released. Because of this, development teams see security requirements as hurdles to pass instead of valuable insights. This isn’t unreasonable, most security teams have set themselves up this way, standing as the last bastion of security. I’ve heard security colleagues even say things like “every vulnerability must be fixed before ship!” With an attitude like that it’s no surprise that development teams aren’t excited to work with security.
Read more >>