Monday, October 17, 2016

Third parties and SSAE 18

My new book talks about building a security program that can pass a number of audits, including the SSAE 16.  Now comes news of a new standard from the AICPA Auditing Standards Board (ASB) called the SSAE 18 that will replace SSAE 16 later in 2017.
Does that mean you need to redo everything? No. I wrote this book with the idea that technology, compliance, and threats will evolve over time.  The advice is designed to be timeless not timely.

There are some changes in how the auditors will conduct and write their opinion, but really one thing that affects the audited organization: increased scrutiny of the performance sub service organizations.  This is another way of talking about third party security.  I have an entire chapter covering that subject in the book.

So what about third party security?   Well, looking at the data from the past three months at the California Attorney General Breach records and I get the following:

Out of the 51 incidents examined, 6 were directly attributable to a third party's security. Is 12% significant?  Sure, maybe not a top risk but it's something to worry about.

So, what is going on with third party security? Protiviti  did a Vendor Risk Management Benchmark Study in 2015 and concluded that"Third party risk management is immature."

Furthermore, they went on to comment that out of all the third party risk management programs going on, the most mature ones are within the financial services organizations.  Good to know, which leads us to ask: how well are financial services organizations managing third party risk? 
Well, the New York State Department of Financial Services issued a "Update on Cyber Security in the Banking Sector: Third Party Service Providers." In this report, they noted that fewer than half of examined financial service companies do on-site assessments and within the programs themselves there is a lot of variation.

Having been on the pointy end of these assessments for nearly a decade, I concur with these findings.  I've seen banks assess vendor security by a large variety of methods including:
They all seem to have varying strengths (accuracy, low cost, speed) and weaknesses (lack of accuracy, difficulty).  For questionnaires, the actual questions always seem to revolve around the standard 27k2 control sets.  Maybe these are sufficient, but does fall victim to best practicism.

Whatever third party security assessment you use, doing something is better than doing nothing.  And if you're going to pursue meeting the SSAE 18 certification, you should invest in a good method.

Monday, October 10, 2016

Assume breach as a foundation of a security program

This picture below was excluded from my new book, IT Security Risk Control Management: An Audit Preparation Plan.

The publishers thought it wouldn't look very good in gray scale print. The story that goes with it is still there in Chapter 2, Assume Breach.

The concept of Assume Breach has been with us for over twenty years and I've been blogging here about it since 2008.

Assume Breach simply means don't count on our security defenses to keep the bad guys out. This picture is of the wall of a supposedly impregnable fortress after it went up against it's first real challenge against new technology.

Quinn Norton also coined a great corollary, called Norton's Law, which states that all data, over time, approaches deleted, or public.

In the book, the assume breach concept forms the foundation of a security program. What does this mean for defenders? It means that if you're going to be breached, you need to know what can be sacrificed and what must be protected at all costs. That implies you understand your organization, it's data flows, and what is truly important for survival. It also means you need to have a clear idea of the threats and vulnerabilities facing you. Lastly, assume breach means being prepared to adequately respond to incidents, survive them, and grow stronger because it.

It's the opposite of common rookie thinking “That’ll never happen in a million years!” or "why would anyone do that?" and instead think "When the inevitable happens, what will the damage look like and how will we react?" Assume breach forces you to focus on what matters and prioritize accordingly. Not a bad way to build a security program.

Saturday, October 1, 2016

The "softside" of Security can be the hardest

I just watched Leigh Honeywell's talk on "Building Secure Cultures" on the YouTubez. (BTW, it is a must watch for anyone remotely involved in security) I've been a big fan of Leigh's work and she lays down a lot of practical and effective advice.  Her talk also struck a chord with me and my recent book on how to build a successful security program to pass audit.

For one, I felt great that she was also emphasizing empathy and coaching when delivering security advice. She, like me, has seen how counter-productive the elitism, abrasiveness, and condescension (and just plain rudeness) that somehow has become associated with a lot of the security industry.   I especially liked how she called out "feigning surprise", an insulting practice I too have been guilty of doing.

"What? You didn't patch it?"

Her talk raises a powerful point: It serves no useful purpose beyond belittling the person seeking advice.  Remember, we want people to bring their security problems to us and report suspicious things.

Those of you who have read my book may have noticed a running theme of working to see things from other people's perspectives.  Yes, it's real work.  In fact, Leigh touches on that in her talk as well (if you haven't watched it, you should).  I've said it before: the hard part of security is sometimes the soft parts. By that I mean managing our feelings.  Sometimes we have to suppress our fear and anger and present a positive face despite what may be a valid emotional response.    This is work -- hard work.  There's even a term for it - Emotional Labor.

Working in security, especially if you're trying to actively improve things in an organization, takes emotional labor.  Many of us are geeks, having worked our way up from the techie trenches to meet the challenge of security work.  The term geek itself should tell you something about our innate people skills and our limits on managing our external personas.  Nevertheless, these soft skills are force multipliers we can leverage for effective security work done.  I've woven practical advice on how to do this into a number of chapters. It's nice to see it called out on its own as a critical success factor in security work.  Empathy is powerful in designing security solutions - how would a non-security tech react to what you think is obvious?  I'm happy to see there is work now starting to blossom in this area.

Being able to modulate our own external outputs is critical not just in social engineering, but in being heard and acknowledged by others.  Yes, listening to the other person before delivering your advice levels up your ability to create meaningful change.

As I said, none of this is easy. But it's definitely worth checking out.

Monday, September 26, 2016

IT Security Risk Control Management: An Audit Preparation Plan - PUBLISHED!

My new book is officially published!

It is available in both electronic and paper form.

After many months of hard work, I am so happy to see the fruits of my labor.

Wednesday, July 27, 2016

IT Security Risk Control Management: An Audit Preparation Plan

I've been quiet for a long, long while.  It hasn't been because I didn't have anything to say.  On the contrary, I've been pouring it all into my soon-to-be-released book, IT Security Risk Control Management: An Audit Preparation Plan.
Before you ask, I didn't come up with the title, the publisher did. The book is aimed at newly minted security professionals or those wanting to step into the security role. It covers how to build a security program from scratch, do the risk analysis, pick controls, implement the controls (in such a manner that they actually work), and then be able to pass an audit.  I specifically chose the SSAE-16/ISAE-3402 (SOCs 1,2,3), PCI DSS, and ISO 27001 as my audit candidates as they are the most common globally.
It'll be out in early October, but you can pre-order now.
I'll be writing more as we get closer to the publication date.

Monday, September 21, 2015

Some updates to vuln visualization

A while ago, I posted about an internal tool I created, Cestus, which I use to help score my vulnerabilities in my environment.   Since then, I've made a few tweaks to the tool.

Specifically, I've added:

  1. Risk-based adjustment based on host importance.  Some hosts are obviously more important than others.  Perimeter-facing mission-critical boxes score individually higher than internal utility servers behind 3 layers of firewalls.   To do this, I had to modify the database and add new fields.  Luckily with SQLite, this was a snap.
  2. Scoring based on type of vulnerability service.  Vulnerabilities that require local access (such as a browser vuln) score lower on servers than external service type of vulnerability does.  Bonus risk points for an external service discovered on what should be a client box.... laptops should not have listening FTP servers on them!
  3. New report on total number of vulnerabilities and total risk score per host.  Handy for shaming informative reports to asset owners.
  4. New report on total number of listening services per host.  Good for seeing which boxes are leaving large footprints on your networks.  And singling out unusual looking devices.  Both have proved very "interesting" when reviewed.  Also good to compare to asset master lists to see if you missed scanning anything.
  5. New report on vulnerabilities based on keyword name in description.  This lets me create useful pie charts on which vendors are causing the most number of vulnerabilities in our environment.  So far these reports haven't been that revelatory:

That's all I've got for now.  I'm still working on integrating this into our on-going threat and IDS data streams. 

Friday, September 11, 2015

Siracon 2015

Excited to be presenting at this year's SiraCon in Detroit

My talk will be on Third Party Risk Assessment Exposed

You hear things like "The majority of breaches occur as the result of third parties." You see a lot of surveys and read a lot of "best practices" around third party security. But what is actually happening in third-party risk assessment? It’s hard enough to measure the risk of your own organization, how can you quickly measure an external organization? Banks are required to do this but specific methods aren't defined. So what are they doing? We’ll examine data from hundreds of external assessments in the financial sector and compare this to actual breach data. We'll look at such questions like: What are the top questions asked by more than half of the assessors? What are questions asked rarely? What factors drive assessments? What important questions are missed? We’ll also dig into the top assessment standards SOC1-2-3, ISO27k, Shared Assessments and see what they’re accomplishing.

Looks to be an awesome lineup this year.  Honored to be a part of it.