Raymond Pompon's Blog, page 13
June 8, 2017
Blogging Elsewhere: How a CISO can play a role in selling security
How a CISO can play a role in selling security
https://f5.com/labs/articles/cisotociso/leadership/how-a-ciso-can-play-a-role-in-selling-security-26942
Anyone in the CISO game knows that you end up having to "sell" the security of your organization to customers and partners... so why not name it and claim it?
Blogging elsewhere: Can your risk assessment stand up under scrutiny?
Can your risk assessment stand up under scrutiny?
https://f5.com/labs/articles/cisotociso/compliance/can-your-risk-assessment-stand-up-under-scrutiny-26784
When something in the news catches my eye, I feel compelled to dig deeper
Blogging elsewhere: 7 Upgrades to level up your security program experience
7 Upgrades to level up your security program experience
https://f5.com/labs/articles/cisotociso/strategy/7-upgrades-to-level-up-your-security-program-experience-26703
A smattering of general advice
Blogging elsewhere: Stalking in the Workplace: What can CISOs do?
Blogging elsewhere: Stalking in the Workplace: What can CISOs do?
https://f5.com/labs/articles/cisotociso/leadership/stalking-in-the-workplace-what-cisos-can-do-26165
A personal one from me. Also covered fictionally via Heidi over here
March 29, 2017
Blogging elsewhere: Can Audits Help Us Trust Third Parties?
Wrote about audit and third parties over at F5 Labs
F5 Labs CISO to CISO:
Can Audits Help Us Trust Third Parties?
F5 Labs CISO to CISO:
Can Audits Help Us Trust Third Parties?
March 17, 2017
Blogging over at F5 Labs
In case you missed it, I've been doing a lot of blogging over at F5 Labs.
The Humanization of the Security Leader: What CISOs Need to Be Successful
When someone from the IT group gets promoted into security management, a common first lesson is that “geek culture” is ineffective in the boardroom. Just watch one episode of The Big Bang Theory and you’ll recognize the classic nerd character...
How Three Low-Risk Vulnerabilities Become One High
Revisting van Beek's Microsoft Exchange Autodiscover vulnerability to make it much deadlier. (Co-author)
Using F5 Labs Application Threat Intelligence
As security professionals, we often feel like we’re fighting a losing battle when it comes to cyber security. (Co-author)
The Risk Pivot: Succeeding with Business Leadership by Quantifying Ops Risk
Getting the security investments you need often comes down to making your case to management in terms of operational risk.
The Conflicting Obligations of a Security Leader
Faced with competing pressures, CISOs are ultimately the experts at assessing what’s truly at stake in their organizations.
Building Secure Solutions Successfully Using Systems Theory
When security solutions don’t work as planned, embrace the complexity and use Systems Theory tools to adjust, regulate, and redefine.
DNS Is Still the Achilles’ Heel of the Internet
Since the Internet can’t survive without DNS, let’s make our best effort to defend it.
Will Deception as a Defense Become Mainstream?
Defensive deception works well, but needs championing before we’ll see it as a best practice or compliance requirement.
Follow the F5 Labs posts via RSS
The Humanization of the Security Leader: What CISOs Need to Be Successful
When someone from the IT group gets promoted into security management, a common first lesson is that “geek culture” is ineffective in the boardroom. Just watch one episode of The Big Bang Theory and you’ll recognize the classic nerd character...
How Three Low-Risk Vulnerabilities Become One High
Revisting van Beek's Microsoft Exchange Autodiscover vulnerability to make it much deadlier. (Co-author)
Using F5 Labs Application Threat Intelligence
As security professionals, we often feel like we’re fighting a losing battle when it comes to cyber security. (Co-author)
The Risk Pivot: Succeeding with Business Leadership by Quantifying Ops Risk
Getting the security investments you need often comes down to making your case to management in terms of operational risk.
The Conflicting Obligations of a Security Leader
Faced with competing pressures, CISOs are ultimately the experts at assessing what’s truly at stake in their organizations.
Building Secure Solutions Successfully Using Systems Theory
When security solutions don’t work as planned, embrace the complexity and use Systems Theory tools to adjust, regulate, and redefine.
DNS Is Still the Achilles’ Heel of the Internet
Since the Internet can’t survive without DNS, let’s make our best effort to defend it.
Will Deception as a Defense Become Mainstream?
Defensive deception works well, but needs championing before we’ll see it as a best practice or compliance requirement.
Follow the F5 Labs posts via RSS
January 17, 2017
December 4, 2016
7 Mistakes of InfoSec defense
I've been reflecting lately on the role of an InfoSec defender. Having written a whole book on the subject forces one to think deeply about the day-to-day job of defense. I've also been interviewing a lot of new people looking to step in my current defender role. I'm seeing a lot of enthusiasm and smart thinking out there. Good stuff.
Unfortunately, I've also seen a few stumbles that I'd like to soapbox on. These are things that seemed like a good idea at first blush (see below) but in reality, not so much.
This isn't an exhaustive list and may not even be the most prevalent problems in the industry, but in my experience, this is what I see cropping up most commonly.
1. Prioritizing controls based only on auditor's demands instead of risk.
When you do this, you waste resources on possibly unnecessary or unimportant risks. Auditors don't know everything and compliance frameworks don't always fit everyone. Beware the fallacy that a missing control is the equivalent of a risk. I've seen it more than once: "We're buying a NAC system because it was a finding in the audit." Is that a significant risk? "Well, not really... I'm not sure. Maybe?" Prioritize based on risk.
2. Prioritizing controls based only on the Headline of the Week.
Egad, IOT DDOS botnets of doom! We need new defenses. Stop, is that an actual risk for your organization? What is the impact of a DDOS? Do the math and figure it out. Sometimes the answer will surprise you.
3. Confusing Impact with Risk.
Impact is one factor of the risk equation. An insider attack where someone steals all your source code will have a huge impact. But is it a big risk? What are the odds of it happening? How about an earthquake? Don't fill up a risk report with just impact statements. Risk is a combination of Impact and Probability of occurrence.
4. Confusing Frequency with Risk.
Similarly, to the previous item, just because something is very likely to happen doesn't mean it will have a big impact on your organization. Many also forget about all the good controls they already in place. I've seen IT folks freak out about the high volume of SSH password brute force attempts... against a server set up to use SSH keys. Or high volumes of TCP Port 1521 probes from the Internet when the database servers are buried deep between 3 layers of firewall and NATed. Very unlikely that these common attacks are actually going to get very far.
5. Overprotecting the wrong thing.
The classic: I have more budget so I'm going to get a new firewall. However, your old firewall is managing things pretty well and you have other serious risks to tackle next. Maybe you need to fix cross-site scripting on your web application or lock down physical access to the server room. Not as fun and sexy as a new firewall but you should make sure all your major risks are controlled before enhancing protection for a particular risk.
6. Deploying shelfware.
You've got a big problem and a vendor offers a big solution. POs are cut and solutions are deployed. Except they're too complicated to manage. Or too cumbersome for users to deal with. Require too much overhead to keep running. Or require more admins than you have staff for. This can also happen when IT and Security don't work together on a solution. Don't waste a bunch of money deploying a giant control that doesn't actually fit in your organization. This has been discussed by others before.
7. Attacking an intractable head on with a supposedly simple solution.
I've seen folks go after the Big Whales of InfoSec risk with nothing but a fishhook and a row boat. Everyone in the organization has "local admin"? Just take away all their rights, we'll roll out a policy and force it through. Yeah, except your organization isn't homogenous in use case or deployed versions of operating systems. This quickly turns into a morass of exceptions and workarounds... and before long the whole thing is abandoned.
Want more examples? How about fixing SQL injection on the web app? Tell the developers to just patch it. Easy to fix, just get them programmers motivated to fix it. Phishing emails? Time for more user training. It's never that easy. If it was, don't you think everyone else would be doing it? As Mencken said, for every complex problem there is an answer that is clear, simple, and wrong. It's not always a straight line to victory so think before you implement.
Sorry for the listicle title. I couldn't resist. :-)
Unfortunately, I've also seen a few stumbles that I'd like to soapbox on. These are things that seemed like a good idea at first blush (see below) but in reality, not so much.
This isn't an exhaustive list and may not even be the most prevalent problems in the industry, but in my experience, this is what I see cropping up most commonly.
1. Prioritizing controls based only on auditor's demands instead of risk.
When you do this, you waste resources on possibly unnecessary or unimportant risks. Auditors don't know everything and compliance frameworks don't always fit everyone. Beware the fallacy that a missing control is the equivalent of a risk. I've seen it more than once: "We're buying a NAC system because it was a finding in the audit." Is that a significant risk? "Well, not really... I'm not sure. Maybe?" Prioritize based on risk.
2. Prioritizing controls based only on the Headline of the Week.
Egad, IOT DDOS botnets of doom! We need new defenses. Stop, is that an actual risk for your organization? What is the impact of a DDOS? Do the math and figure it out. Sometimes the answer will surprise you.
3. Confusing Impact with Risk.
Impact is one factor of the risk equation. An insider attack where someone steals all your source code will have a huge impact. But is it a big risk? What are the odds of it happening? How about an earthquake? Don't fill up a risk report with just impact statements. Risk is a combination of Impact and Probability of occurrence.
4. Confusing Frequency with Risk.
Similarly, to the previous item, just because something is very likely to happen doesn't mean it will have a big impact on your organization. Many also forget about all the good controls they already in place. I've seen IT folks freak out about the high volume of SSH password brute force attempts... against a server set up to use SSH keys. Or high volumes of TCP Port 1521 probes from the Internet when the database servers are buried deep between 3 layers of firewall and NATed. Very unlikely that these common attacks are actually going to get very far.
5. Overprotecting the wrong thing.
The classic: I have more budget so I'm going to get a new firewall. However, your old firewall is managing things pretty well and you have other serious risks to tackle next. Maybe you need to fix cross-site scripting on your web application or lock down physical access to the server room. Not as fun and sexy as a new firewall but you should make sure all your major risks are controlled before enhancing protection for a particular risk.
6. Deploying shelfware.
You've got a big problem and a vendor offers a big solution. POs are cut and solutions are deployed. Except they're too complicated to manage. Or too cumbersome for users to deal with. Require too much overhead to keep running. Or require more admins than you have staff for. This can also happen when IT and Security don't work together on a solution. Don't waste a bunch of money deploying a giant control that doesn't actually fit in your organization. This has been discussed by others before.
7. Attacking an intractable head on with a supposedly simple solution.
I've seen folks go after the Big Whales of InfoSec risk with nothing but a fishhook and a row boat. Everyone in the organization has "local admin"? Just take away all their rights, we'll roll out a policy and force it through. Yeah, except your organization isn't homogenous in use case or deployed versions of operating systems. This quickly turns into a morass of exceptions and workarounds... and before long the whole thing is abandoned.
Want more examples? How about fixing SQL injection on the web app? Tell the developers to just patch it. Easy to fix, just get them programmers motivated to fix it. Phishing emails? Time for more user training. It's never that easy. If it was, don't you think everyone else would be doing it? As Mencken said, for every complex problem there is an answer that is clear, simple, and wrong. It's not always a straight line to victory so think before you implement.
Sorry for the listicle title. I couldn't resist. :-)
November 28, 2016
First review of "IT Security Risk Control Management: An Audit Preparation Plan"
Bowling Green Daily News has a pretty comprehensive review of my new book.
'IT Security' finally starts to make sense
