Friday, April 10, 2015

Questioning your security data

Everyone's getting excited about big data for security.  The tools get fancier and give you a lot more data, but I barely see folks using them for much else than producing pretty graphs for management.  Some security pros use this data to figure out where to focus their remediation.  Some seem to think that our magic SEIM boxes will detect the RFC 3514 tagged packets.  No such luck.

As Lévi-Strauss said, “The scientist is not a person who gives the right answers, he's one who asks the right questions.”  So what am I trying to get out of my Big Pile of Security data? 

Have I been pwned?

I want to know which of my boxes have been hacked, what are the effects and how certain can we be about that.  The effects that I’m concerned about are: did they steal data or credentials?  Did they plant malware?  Or is it just ransomware or for click fraud?

Am I under active targeted attack?

 Just being on the Internet means Im under attack.  I want know if someone has singled my organization out and knows where to hit me and how hard.  And how long has this been going on?  Can I identify the attackers, what else have they done that might be slipping under my radar?

What is changing on my critical systems?

Change management is a critical piece of good IT hygiene and operational sanity.  The key is detecting unauthorized changes.   When things start getting modified that you dont know about, it almost always means something bad is going on.

What is the state of the background radiation of the Internet?

I also want to know about the non-directed attacks that are just sweeping across the Internet.  What is being targeted now?  What ports are getting a lot of attention?  Does what Im seeing match up to what everyone else is seeing?  How visible is my Internet footprint?  What kinds of exploits are in use?  What malware is popular this week?

What can you tell me all about this particular IP address?

Is it a customer?  Is it one of my road warriors?  Is it a security researcher or a vulnerability tester?  Is it someone Ive never seen before? How suspicious has it been?  What do other organizations think about it?

What are you seeing that you didnt see yesterday?

As Marcus Ranum said, "By definition, something we have never seen before is anomalous  It may be evil or maybe that Operations changed something.  But its always useful to know.

So that's what I'm looking for in my great collections of security data.  What are you doing with yours?

Thursday, December 18, 2014

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.

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?

Friday, November 21, 2014

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.

Thursday, September 11, 2014

How to interview security people

Good security people are in demand.  Emphasis on good.  We all don’t need any more paper-tigers toting the certs and zero useful skills.  Sometimes you can spot these folks on a resume but the last line of defense is the interview.

One problem I’ve seen for a lot of organizations filling their first security position is that the hiring team is unaware of how to interview for security.  So you can end up with someone with a serious skill gap.  And unfortunately, as the security program is built and staffed up, this already unqualified person then hires in more unqualified people.   As Rumsfeld said, “A’s hire A’s, B’s hire C’s.“  So it’s best to get this right in the beginning.

Evaluating security skills is tough.  So much so that my organization usually does dual interviews, sometimes triple.  One for cultural/team fit (which is often the hardest and weeds out a lot of people fast) and them a separate interview on technical topics.

But again, security technical interviews are tough if you don’t already have those skills in-house and can’t hire in a consultant to help in hiring.  As Dan Geer says, "cybersecurity is perhaps the most intellectually demanding occupation on the planet.”  So how do you evaluate that?

So what do you do?  Well, let’s step back and look at a  simple model of skills:

Now, we have a basic idea of the spectrum.  The next important thing is to look closely at the actual skills to do the job. For a lot of security folks, there’s a lot skills needed that aren’t about deciphering malware, configuring firewalls, decoding IDS traces, or hacking web servers.  A lot of security people, and even people who’s job title is simply “sysadmin”, need skills along the lines of risk judgement, security architecture, the spectrum of threats, and compliance issues.  Almost all of these topics are covered deeply in certifications and classes, except for good risk judgement.  And tellingly, that’s where I see a lot of security candidates falter.

So consider that fundamental skills, a good interview question would be to ask “Tell me about how do you risk analysis”

Another would be to give them an opportunity to demonstrate, with either a hypothetical question or asking them to tell you about a situation where they had to navigate the gray areas of risk.

Here’s an example of hypothetical and how I would think someone of various skill levels would answer:

“A business unit just inked a new deal where we’re going to be retrieving our daily TPS reports from an SFTP server in the cloud.  The cloud provider is SSAE audited and is willing to work with us on security.  What risks do you report back to your Director of Ops about this connection?"

“Cloud?  First of all, that’s a huge issue.  And audited, SSAE is like SAS-70, so that’s pretty not bad.  But there are still a lot of security problems with the cloud.   That’s a big risk there.  FTP?  No wait, you said SFTP.  That means the connection is encrypted, okay. I’m mostly concerned about malware.  I didn’t hear anything about anti-virus being used on the connection.  Just because the server is Linux doesn’t mean they can’t get a virus."

Advanced beginner 
“Cloud is audited?  SSAE?  Type 1 or Type 2? Okay, what else? Cloud Security Alliance?  SFTP is okay, but how is it authenticating?  Password?  What are the password rules? How often is it rotated? And what’s in the file?  I'd like to nmap that SFTP server too."

Proficient - prioritizes importance of aspects, employs maxims
“First off, what’s in the file.  Is it just documents?  It sounds like it, but is there PII in them?  SFTP file transfer is okay but since is this automated?  If so, are we using SSH keys?  Cloud provider says SSAE, is that Type 1 or Type 2, and SOC 1, 2 or 3?  What other certifications or audits do they have?   Is that server hardened?"

Expert - "intuitive grasp of situations based on deep, tacit understanding"
“First off, I'm excited to hear the cloud provider is willing to work with us. That tells us a lot about how well this will turn out.   Okay, onto the risl.  A lot depends on the nature of the files transferred.  If they have confidential data in them, then we need to look at a lot of things: is the file encrypted at rest in addition to the SFTP encryption, whatever that is.  I’d make sure the level of encryption AND authentication on the SSH session matches the need, not just risk but also for compliance.  Same goes for the Cloud provider.  They’re audited but what’s the scope?  Does it include servers hosted by them or just their infrastructure?  Is that SFTP server covered? And what levels? And I’d need to see the actual SSAE report so I can read it for scope, relevance and standards.” 

Note how at the highest level, there's an immediate realization that this whole project is being driven for a business purpose.  And the implies that your job as a security professional is to make this work in a safe and sane manner... not stomp all over some possibly important money-making process and shut down a project for compliance reasons.

Okay, another example:  “We have Jericho firewalls.  Tell me about your experience with them?”

“Jericho firewalls?  They suck. Remember the ram’s horn vulnerability they had two years ago? First thing I’d do is replace ‘em. And I know just how to do that.”

To me, this is the worst possible answer. This is someone who, without ever seeing our infrastructure or doing a risk analysis, has already decided what our highest priority is and is willing to commit resources to it. This is not a security professional I’d want on my team.

As someone who never has touched a Jericho firewall, I’d say something like “Well, I’ve never actually heard of them… which is strange since I have hands-on experience implementing and auditing many major firewalls (then I’d list the manufacturers and my experiences/certs) But I’m confident I’d be able to figure them out how they work.  Hmm, what was it you’d be expecting me to do with them?”

Now in this case, I’ve qualified my experience and have shown that I need to open a dialog about the nature of the control before proceeding any further.  At this point, it gives me a chance to shine (or fog up) as I probe and analyze their firewall requirements.  And if you as an interviewer are worried about giving away too much internal information in an interview, use made-up or outdated information for the dialog.  Of course, you should have NDAed and vetted the candidate before getting to this point.

Assuming you have NDAed and done basic vetting of the candidate, a useful assessment is to have them review an old audit or vulnerability assessment report of yours in front of you.  Their initial impressions will tell you a lot about their security philosophy - Yes, everyone has a security philosophy.  This field is too new and too fluid for rigid "best practices" to remain relevant1.  Pay particularly close attention to the candidate's comments on compliance.  Ideally, you want attorney-level knowledge of your compliance requirements.  This gets back to the Dreyfus model.  A novice will know the basic compliance rules.  Someone more skilled will understand the "case law" and how the compliance requirement is interpreted in the real world.  A highly skilled individual will work from the intent of the rule and even know how the rule is subverted.

One of the last key elements in a strong security candidate, of any skill level, is their enthusiasm.  This is a tough and often thankless job.  If they've been in the job long enough, they've, as Dan Geer says, sadder but wiser.

I've seen a lot of burned out security professionals either as bitter as an old lemon rind or sleeping walking through the job.  One thing to look for is do they have a "constant learning" attitude.  Ask about what they're interested in learning next in security. Ask what the big challenges in the field are for them and how they plan to meet them.  Ask if they teach or mentor or write about security.  These are all good indicators of someone who enjoys the field and is trying to improve.

Whew. Once again this blog post has rambled on and on.  That's enough for now.  Got questions or comments on how you hire security people?  Fire away.

1 - And I realize that attitude in itself is a philosophy.

Thursday, August 7, 2014

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?