Our Gray Cyber Future

This post by Bruce Schneier kicked off an idea that's been rattling around in my head for a year or three...The future of cyber-security is indeed looking more and more gray.   Gray as in gray hat... as in more and more "bad guy" techniques being adopted by good guys.  We're going to see continued growth in offensive hacking techniques migrating from attacker to defender, just so defenders can keep up.   And bad guys are going to get even more bad.

As if things weren't already gray enough, with some security professionals jumping back and forth across the line from blackhat to whitehat and vice-versa. 

As Richard Thieme famously pointed out, in the near future the edge will move to be the center. To see the future of the mainstream, we only need look at the edge. So what is happening at the edge?

The Age of Mega-Threats

We're moving into a time of invisible cyber-wars between nation-states, NGOs and multinationals.  Not to mention large scale industrial espionage, DDOS and revenge hacking and major corporations getting whacked by semi-cloaked villains.

We can see the rise of true super villains - individuals who can cause massive cyber-damage.  Not just folks like Snowden, but what about the mega-Botmasters and mercenary super hacker-for-hire.  We're really only one good 0-day in the wrong hands from someone shutting down the Internet for a few days.  Large scale automation of attacks allows one person could direct an attack of millions of bots or use them as their own private surveillance network

Law Enforcement Response

Like they have in the face of terrorism and the war on drugs, LE is going to move away from the clean-cut traditional police methods and use more... let's say, aggressive "out-of-the-box" response techniques.  We started with the usual deceptive law enforcement tools:  stings and informant-baited traps... To deals with the questionable folks... collaboration with Internet providers to spy on people, surveillance in the soft areas of the law, spyware injections, and now outright hacking and social engineering.

The Private Sector Response

We in the private sector don't have the legal authority to hack and lie outright, but we're still definitely adopting more and more gray hat techniques.  We now have massive private intelligence operations with private undercover agents in the hacker underground, honey pots to trap and collect intel, reputation tracking and semi-secret threat sharing organizations.  As Dan Geer said, "We're all intelligence officers now."

But that's just the beginning.  There is a strong movement towards active-response.  And  more outsourced security and tech-giants doing “what’s necessary” to clean up the Internet.  There are also quieter semi-active responses going on: large scale black-list shunning, false data injections and active deception, and tar pitting.

I'm talking about escalation

The next step on the downward spiral would be cyber-privateers hired by victim companies to mete out retribution against attackers on the open Internet by means fair and foul.  And the bad guys and APTs stepping up their game to respond. With everyone else caught in the cross-fire.

PS: I know one can say this is reflective of our times, and you may be right.  But is that the future we want?

Tabbforum: Staying Ahead of the Looming InfoSec Crunch

Posting at the Tabbforum -

Staying Ahead of the Looming InfoSec Crunch

The Spoon Model

The spoon theory describes the daily life of people with medical conditions and their limited energy resources for doing seemingly everyday tasks. The model goes like this: each day you’re given a handful of spoons, which you will use for an activity. When the spoons are used up, you need to lay down until the next day. The difference between healthy people as they have an ever-renewing amount of spoons and can push themselves. while the medically-challenged must work within their limited allotment.

“Most people start the day with unlimited amount of possibilities, and energy to do whatever they desire, especially young people. For the most part, they do not need to worry about the effects of their actions.”

Just the daily tasks associated with living (getting dressed, making breakfast, getting on the bus) will cost spoons. Often once these spoons are allotted, there are aren’t many left for extra activities. Furthermore, simple problem like skipping a meal or being too cold can reduce the spoon allocation to the point where even normal activity is beyond the budget. Sometimes even pushing or overspending the spoon budget can seriously reduce the number of spoons available for the next few days.

It’s a very good and highly recommended read to understand how life is with a chronic illness or disability. I also think it’s a good metaphor for the daily workload of a IT worker.

I think folks outside of IT (and especially management) think they are like healthy people with boundless energy. However, most IT shops are burdened with technical debt dealing with poorly installed or poorly implemented software and architecture. They only have so many spoons! So when we security folks come in with “You need to patch everything right now!” 

Boom! All the spoons are gone. That means less time for other things that might affect your risk profile, like fixing broken anti-virus, monitoring & responding to security alerts, encrypting laptops, and removing accounts for terminated users. And this doesn’t count all the other things IT has to deal with that affect uptime, their user’s satisfaction and their own sanity.

I’m not sure every security professional realizes that they need to remember that IT has only so many spoons and only so many requests are going to be followed through on. We all need to plan carefully less we make things worse.

Things used interchangeably that are not

I keep seeing security "professionals" mixing and matching terms interchangeably that are not.  I can understand this confusion from a user or a PHB, but not from a security professional.   I mix conflating these terms should result in automatic disbarment of whatever the latest security certification that person is holding.  Considering how tricky security and assurance work already is, it'd be really nice if we all used the same terms for some of the most basic things we do.

The terms I most often see conflated or misused for each other are:


Privacy and Confidentiality
Privacy relates to a person, Confidentiality relates to information about a person.  It gets awkward when folks ask for a privacy policy when they really mean confidentiality policy.   A privacy policy would talk about how I handle (collect, use, retain and disclose) someone’s data.  A confidentiality policy talks about how I protect it.


Vulnerability scan and Penetration test
You can often get a vuln scan as part of a pen-test, but they really aren't the same thing.  The tip-off should be the word "penetration" which means someone is actually breaking in instead of just looking at you.   One usually costs a lot more than the other as well.  Bonus: a port scan is part of a vulnerability scan, but not the whole thing.




Vulnerability/Threat/Impact and Risk
I'm a proud member of SIRA, where a bunch of nerds sit around to argue about different risk models and which fits/works best in what situation.  But you know what?  I'd be happy if the entire industry just started using the most basic simplistic formula for risk: Risk = Threat × Probability × Impact.  Sadly, what I see folks doing is:

1. "We need to stop doing this because APTs are dangerous" -> Risk = Threat
2. "We need to shut down email because half our messages have malware in them" -> Risk = Probability
3. "We need to do something about DDOS because our site could go down." -> Risk = Impact

No.  You aren't thinking this through.  And you're confusing the users.  Stop it.

Disaster Recovery and Business Continuity
Again, the tip-off is in the words themselves.  Disaster recovery is about recovering the IT systems after a disaster.  Just the IT systems.  Business continuity involves recovering the entire business process.  BC can include DR but not the other way around.

2 factor and additional authentication
You know when you login to your web banking from a new computer and it suddenly asks you what high school you went to?  That's not 2-factor authentication... because that's just more of "something you know." It's layered or risk-based or adaptive authentication.  But it's not a different factor so it's not as strong.  So stop thinking that it is.

What do you see security professionals mixing up all the time?

Great blog

So I stumbled across this blog post the other day and really liked it. If I wasn't so lazy, I'd rewrite it, replacing all the references to the development projects with security/risk mitigation projects.

But I am lazy, so read it yourself and make the replacement in your head.

It's a must read for anyone in the security biz communicating or managing risk to the business folks (in others, almost everyone in security)

No Deadlines For You! Software Dev Without Estimates, Specs or Other Lies

Seriously, go read it.  It's great.

7 areas outside of infosec to study

There's a lot of areas that most of us infosec people like to dabble in that is outside of our required skill set. For example, it seems like every third security person has a set of lock picks and loves to do it. Unless you're a red teamer, admit that it's just a puzzle you like to play with and stop trying to impress us. Here are some areas just outside of infosec that I like it to hone:

1. SEO - Becuz hackers use it to sneak malware into your organization. Information warfare is older school than “cyber warfare”, and information warfare is all about managing perception. Where to start? I recommend my neighbor, Moz

2. Effective communication. That means learning to write well in both email, long form, and to educate. It means being to speak effectively one-on-one, in a meeting, and giving a speech. It means being clear, concise and consistent. It means respecting your audience and establishing rapport. Where to start? I recommend Manager Tools

3. Project Management. Everything we do is a project. We can always be better at doing them. I’ve been managing projects for decades and I’m still not satisfied on how well things are run. I recommend Herding Cats.

4. Programming. I started in programming but rarely do it anymore. We work in technology. We give advice to developers. We work with sysadmins on scripting. We should at least have a good fundamental grasp of programming in a few major flavors: basic automation scripting, web apps, and short executables. I’d say you should at least be able create something useful (beyond Hello World) in PERL, Bash, or PowerShell… plus something in Ruby/Python/Java.

5. Databases. Most of everything is built on on a database. You should at least be able to write queries and understand how tables and indices work. It’s helpful to know a little more than how to do a SQL inject “drop tables” or “Select *”. You don’t need to become a DBA but tinker with SQLite or MySQL. As I level-up on item 4, I find myself doing more and more of number 5. They kinda go together.

6. Psychology. Since we can't solve all our security problems with money (cuz we don't have enough) we have to use influence to get things done. And we have to anticipate how controls will live or die in the real world. A good basic understanding of people beyond treating users as passive objects (or even worset, as rational actors) is required. A good starting place is Dan Ariely's Predictably Irrational: The Hidden Forces That Shape Our Decisions.

7. Behavioral economics (More psychology) If you ever wondered why I have a CISSP, do SSAE-16 audits, and have an office shelf of security awards, it’s because I get visited by a lot of nervous customers and auditors entrusting me with their data. And signaling theory.

Note how almost have the things on my list are human-centric areas… because the people are always the hardest part of the job.

An interesting tidbit in the EU data protection regs:

The European Parliament has finally passed their big redesign of data protection regulation. Nothing too shocking in there, in light of the Snowden fallout. One little item caught my eye tho:

 Data Protection Officers: the controller and the processor shall designate a data protection officer inter alia, where the processing is carried out by a legal person and relates to more than 5000 data subjects in any consecutive 12-month period.

Data protection officers shall be bound by secrecy concerning the identity of data subjects and concerning circumstances enabling data subjects to be identified, unless they are released from that obligation by the data subject. The committee changed the criterion from the number of employees a company has (the Commission suggested at least 250), to the number of data subjects. DPOs should be appointed for at least four years in the case of employees and two in that of external contractors.

The Commission proposed two years in both cases.

Data protection officers should be in a position to perform their duties and tasks independently and enjoy special protection against dismissal. Final responsibility should stay with the management of an organisation.

The data protection officer should be consulted prior to the design, procurement, development and setting-up of systems for the automated processing of personal data, in order to ensure the principles of privacy by design and privacy by default.

Not anything new here, but reviewing it made me thing about an interesting metric buried in there: the controller and the processor shall designate a data protection officer inter alia, where the processing is carried out by a legal person and relates to more than 5000 data subjects in any consecutive 12-month period ... The committee changed the criterion from the number of employees a company has (the Commission suggested at least 250), to the number of data subjects

First I liked the old metric of 250 employees per data protection officer. It tracked with my experience with about the right size to start having a dedicated security officer. But changing it to the size of pile of confidential data you're protecting is even more relevant.

When I was hired on in my current job, we were a smallish company but we were custodians of megatons of PII. And 5000 sounds about right, if nothing else, for breach numbers: If the average cost is around $136 per person's records breached, then 5000 x $136 = $680,000.

Okay, now we have our impact. The question is what is the probability of breach and how much does a dedicated DPO reduce that probability? Well, that probably varies on organization to organization, tho it'd be good to know some hard numbers. Something to munch on.

The other thing I liked in the regs is Data protection officers should be in a position to perform their duties and tasks independently which continues to support my position that infosec should not report into the IT hierarchy.