I’ve just finished Malcolm Gladwell’s book The Tipping Point. As usual, Gladwell’s books always bring food for thought on security for me. Security is deeply related to human behaviour, the main subject of his books. The most interesting thing from TP for security is the Dunbar’s number. Honestly, when I read about it I thought I’ve found something like the famous 42, but it was, in fact, some serious and important stuff for our field.
The basic concept on Dunbar’s number is that people has a limit for the number of people with whom they can maintain stable social relationships. The actual number, 150, was found in several independent studies, including some new ones about social networking websites like Facebook. The implications of this “hard-coded limit” goes beyond the number of “friends” you can have, as it also relates to the number of people that you can interact while maintaining a personal context, the maximum number of people you can put together as a cohesive group, the list of implications is huge.
It’s easy to extrapolate it to security. I can clearly see how it would impact Security Awareness initiatives. It’s common to see those initiatives trying to use people as champions for their work groups and departments. The Dunbar’s number can be used as rule to define how many champions are necessary and for what groups. It can also be used to define processes around access verification and entitlement review, as we can probably expect that a manager won’t be able to effectively answer for “need to know” characteristics of a group bigger than 150 people.
Of course, all these theories need to be tested. However, we must always remember that systems are not only systems to be secured, they have a purpose and they need to perform properly. People are not just “users” they are also human beings. Information is not only data to be protected, it has an infinite range of meanings and context. All research and findings about the Dunbar’s number and its applicability into Information Security is just another example of why is so important to security professionals to constantly go through other fields looking for useful information.
There’s a lot of interesting discussions about the value of SIEM solutions. There’s also some discussions about the possibility of doing that with open source, like OSSIM (I personally think it is possible for some organizations – specially those that have the open source culture already).
I like to say that SIEMs are for security what ERP systems are for enterprise management. There is a huge value on deploying those systems, but you need to be aware that the implementation process is not easy, it takes time and requires a lot of commitment from the organization. It’s not just “pay software, pay hardware, a bunch of consultants, done”. Most of the times you need to create or adapt a lot of process to start working with the new tool. You need to understand the data that you will be working with. Just like for ERPs, when you need to have total control over how your books work in order to automate and improve them, you also need to understand how your network and systems work in order to get any value from SIEMs.
IDSes suffered a lot when they were deployed without the necessary services and (right) people to manage and operate them. SIEMs are not different on this aspect, and they may be even more sensitive about it, because they rely on receiving data from lots of different sources. If those who are responsible for those sources are not in the same boat as you and are not aware of the value of the tool, they have the power to make that SIEM a nightmare to manage. In order to get some value from SIEMs, you need to be able to get the data from the systems you identify as necessary and keep that data flowing! How many places you know where the biggest SIEM related activity is troubleshooting why the logs are not coming? If you cannot feed the beast, it won’t fly.
I was happy to see the last posts from Alan Shimel about the incident on LxLabs and what that means to “cloud security”. Not only because I think he is right about using it as an example of why we should think about cloud security but also because I like his “anti-hype” posture. Ok, that specific incident may be related only to one of the several aspects that define “the cloud” (according to Hoff, “multi-tenancy” – and the implications are mostly to “public Cloud providers”), but that doesn’t mean that it there is no implications on cloud security discussions. And I’ll try to go even further on this analysis.
If you look at the incident characteristics it’s easy to relate that only to multy-tenancy environments, but this can also be seen as a sign of higher impacts (and rewards to attackers) when leveraging components to multiple users, users being not only multiple organizations but also multiple applications, guest OSes, networks or anything else that can share a common resource base. Sharing an (elastic, on demand, whatever) common resource base is probably one of they concepts of cloud computing, so yes, we should connect that incident to cloud security. It’s not a “one to one” relationship, but it makes sense to look into the causes and effects of that fact under “cloud glasses” (WOW, I’ve just created a cloud-hype-term!). And that’s also why I think that Schneier is not completely wrong when he says that we have been there before. We have been sharing computing resources from some time, let’s look into the old stuff without prejudice and see what lessons learned at that time can be applied to the new context. I’m sure we can use a few.
Some interesting aspects that can be highlighted from this incident is how the security dependencies can sharply increase when you start to leverage cloud based services. Suddenly, the security of your data starts to depend not only on the security of the software and hardware that you own, but also on the security of software and hardware of the several service providers that are part of that offering. So, you are using Saas from X? Ok, and they are running their application over PaaS from Y, who operates over IaaS from Z. You are seeing X, but your security now depends on X, Y and Z. How can we do risk assessment for that? I’m not saying that it’s god or bad, just that it has interesting implications about risk management and trust.
Yes Alan, cloud security matters and LxLabs is a very good example to use.
The PCI-DSS world has just gone mad this week after Merrick Bank decided to sue Savvis, who gave a clean bill to the well known service provider CardSystems, responsible for a huge breach that lead to thousands of card numbers being stolen.
It is an interesting outcome and raises a series of questions about whether it’s valid/reasonable to sue an auditor after a breach. Some PCI specialists promptly said it should not happen, as the auditor report is related only to a specific point in time and cannot be taken as a guarantee that nothing will happen on that environment. However, I believe that there are situations that could lead to a lawsuit like that.
If the breach happened through something that goes against a PCI requirement and it was there at the time of the audit, it was probably something that should have been identified by the auditors, so they screwed up.
- “please show me where I’m screwing up”
- “don’t worry you are ok, go for it!”
…something happens…you’ve just opened a can of worms!
Can you show that it was something that the auditors should have found? Was it there at that time? Have you answered properly all questions?
There are other interesting situations – things tested by sampling, incorrect scope definitions, among others.
PCI is suffering from the same pain that SOX suffers…but it will be easier to deal with as it is more prescriptive. Auditors now need to be even more careful about their methodologies – are they doing sampling properly? Are they being careful about the definition of the audit scope? Are they properly registering the answers provided by the audited
organization? That’s how they need to work to protect theirselves from being sued by compromised clients. That and raising their prices to build a reserve for eventual legal expenses. One can expect PCI audits to become more expensive
if the trend is confirmed.
An interesting outcome is that for companies being audited, this is an additional reason to be completely transparent during a PCI audit. If you have the option to sue the auditor later, you should do everything to ensure that they won’t miss anything because of your actions and answers, as this would release them from the liability.
Also, another player will become extremely important, the forensics guy. He’ll be the one that will have to go through all the evidence from the breach investigation and from the audit process to check whether it’s case for a lawsuit.
Auditors trying to protect theirselves by being more efficient, audited companies protecting theirselves by being more transparent. Bad auditors paying for their incompetence. Aren’t these good reasons to allow those lawsuits to happen?
I agree with Ben Tomhave on this particular subject. He is basically saying that we still don’t have a good solution for reliable and repeatable risk assessments. I must say that this is not true to smaller scopes, like a single application or a small network or system. However, when we start talking about a risk assessment for an entire organization, I really don’t trust the results.
A lot of people will say that this is not true, as they’ve already completed successfully several assessments. For those I would ask, do you think that just by delivering a methodology you can ensure that the results would be the same for any other (competent) security professional? Until we can answer that with a sounding “YES”, I don’t think we’ve developed a good enough methodology for risk assessments. In short, I want to see a methodology that brings results that can used to:
- Compare the risk from different organizations (benchmarking!)
- Compare the risk for the same organization in different points of time
- Identify a comfortable level of risk that will be pursued by the implementation of security measures
- Identify the results of applying security measures (answering the basic question, “was it helpful/worth doing?”)
- Compare the risk from two or more different business processes, components or approaches
- Protect against “black swans” (this one is extremely hard)
It should also:
- Include “blind spots” from the organization into the risk calculation
- Consider the interdependency of different business and technology processes and components (how much risk are your production systems inheriting from your development systems?)
- Be resilient to the fact that almost all medium/big organizations have very high levels of uncertainty on the different variables usually necessary for a meaningful risk calculation
That’s not easy and most of the current methodologies cannot address all these issues. That’s the fun part in our job today, we need to find how to do it.
I agree with Andrew Hay here:
For
anyone who has worked in a “front line” customer facing telephone
support role, the answer is almost always am emphatic “YES”. I tend to
agree with my colleagues for one simple reason – embitterment helps you succeed.
Why do I think IT folks need to have a sprinkle of bitterness be in
this field? The fact is that IT, like roadkill removal, is truly a
thankless job. Sure, guidance counselors, parents, and the media will
all tell you that “Computers are the way to go” for a good salary,
benefits, and career advancement. The problem with that mentality is
that it’s not the mid-1980’s anymore. More and more jobs are being
moved to parts of the world where wages are lower and, to be perfectly
frank, people are willing to do the crappy jobs that North Americans
think are beneath them.
To be clear, I’m not saying that working in IT is the hardest, or
worst, job around. IT workers are taken for granted, much like the
aforementioned roadkill removal worker. Most people enjoy driving to
work on a road free from dead animals. When an animal gets run over and
left for dead, the roadkill removal person is dispatched to “dispose”
of the remains. When was the last time you sent a “thank you” card to
your roadkill removal person? To that end, when was the last time you
sent a “thank you” card to a member of your IT department? Show of
hands?
Now let’s jump back to my original topic with a metaphor: an IT
career is like a human body and, in order for your career to live a
long and healthy life, you need a nice thick layer of skin to protect
you from infection. The “infection” in this metaphor referrers to the
emotional challenges that every IT professional experiences during
their career. In order for IT personnel to adequately quote with the
critical thinking required to overcome most IT related challenges, a
“thick skin” is a requirement — one that I believe should show up on
most job postings.
Working on the front lines of an IT organization let’s you
experience what it’s like to sympathize, and empathize, with those who
are having the problems. It lets you develop valuable customer service
and communications skills while you work towards making the customer
happy. Along the way you’ll have numerous bad experiences which will
serve as lessons that you can use to make yourself a better person.
No matter what role you hold within an organization, you have
customers to answer to. This is something that working the front lines
forces you to remember. Good or bad, working in the trenches teaches
you valuable life lessons that will only help you grow as an IT
professional.
The help desk is the best place to see how those incredibly nice projects fail, cause problems or are twisted to be used for different purposes (and bringing different risks). Working there for some time will help to create that “wait a minute, this will cause issues” mindset that is so valuable for the security professional.
This SANS Diary entry from Bojan Zdrnja is a very good explanation about how an apparently non-exploitable SQL Injection condition can be used to get important information from the database. Just by looking at one of the sample injected SQL statements you can see how complex a SQL Injection attack can be:
event = tr’ || (select case
when substr(banner, 1, 1) = ‘A’ then ‘u’ else ‘X’ end from (select
banner from v$version where banner like ‘%Oracle%’)) || ‘e
Read the full story here.
Trying to be compliant PCI is a tough task. One of the biggest problems is to find good answers to common questions, as the “PCI specialists” are usually very evasive and will hardly give you a definitive answer. So, it’s extremely valuable when someone posts a set of common Q&A about the subject like this one from Anton Chuvakin. If you are struggling with PCI, you will find a lot of good information there. Below are some of the most common I’ve seen, with the responses from the “PCI DSS Myths and Misconceptions webinar”:
Q: What about the organization that says “but we use authorize.net, PayPal, Google Checkout (or whoever) to process our card payments for items we sell on the web. We don’t ever handle the card data ourselves, so we don’t need to worry about PCI…do we?”
A: Indeed, outsourcing credit card data processing is a very good way of reducing the scope of your PCI compliant environment. However , it is not the same as “outsourcing PCI DSS” since it does not completely shield you from PCI DSS requirements. “Scope reduction” is NOT “PCI elimination.” There are still areas where you must make an effort to comply. However, PCI Qualified Security Assessor (QSA) is the authorized source of this information.
Q: Is a QSA the only authorized entity to run a scan or can I as the owner of our business run the scan myself?
A: This is a pure misconception; 100% false. As per PCI DSS requirement 11.2, an approved scanning vendor (PCI ASV vendor) must be used for external (=Internet-visible) scanning. Internal scanning can be performed by yourself or anybody else skilled in using a vulnerability scanner.
Q: Do we need to ensure that our third party fulfillment company is PCI DSS compliant as well (especially if they are taking credit card numbers for our customers)?
A: It is hard to say how the contracts are written in such case, but often the answer is indeed “yes.” Moreover, if they take credit cards they need to be compliant and protect the data regardless of their relationship with you. PCI QSA is the authorized source of this information.
Q: Is a fax with credit card information that arrives to organization’s fax server considered to be a digital copy of this data?
A: A digital fax containing a credit card number is likely in scope for PCI DSS. There is some debate about the “pre-authorization data”, but protecting credit card information applies to all types of information: print, files, databases, fax, email, logs, etc.
Q: For a small merchant that only processes a handful of transactions a month, are there alternatives to some of the expensive technology requirements (e.g. application firewalls, independent web/db servers, etc)?
A: Outsourcing credit card transactions is likely the right answer in such circumstances.
The last Verizon reports brought a lot of very good numbers to the Information Security space, so much in need for reliable data. There is always the risk of people using numbers in a wrong way, falling into the famous “base rate fallacy” class of mistakes.
Check Pete Lindstrom comments on it, they perfectly illustrate how easy is to get wrong conclusions from those numbers. For me it’s just another reason to believe that risk calculations are not as useful as we believe.
