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.
Read more >>
Purpose 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.
Application Security An effective application security program will reduce security risk associated with code development while keeping disruption to the normal SDLC processes to a minimum.
Read more >>
This is part of a series Introduction Awareness (you are here) Enablement (coming soon) Enforcement (coming soon) 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.
Read more >>
This is part of a series Introduction (you are here) Awareness Enablement (coming soon) Enforcement (coming soon) 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.
Read more >>
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 >>
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 >>
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.
Read more >>
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.
Read more >>
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.
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.
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.
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.
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!
Read more >>