Risk assessment science

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.

Helpdesk, a very good start to shape your mindset

I agree with Andrew Hay here:

Should the Helpdesk be a Mandatory Start for an IT Career?

Foranyone who has worked in a “front line” customer facing telephonesupport role, the answer is almost always am emphatic “YES”. I tend toagree 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 inthis field? The fact is that IT, like roadkill removal, is truly athankless job. Sure, guidance counselors, parents, and the media willall tell you that “Computers are the way to go” for a good salary,benefits, and career advancement. The problem with that mentality isthat it’s not the mid-1980’s anymore. More and more jobs are beingmoved to parts of the world where wages are lower and, to be perfectlyfrank, people are willing to do the crappy jobs that North Americansthink are beneath them.

To be clear, I’m not saying that working in IT is the hardest, orworst, job around. IT workers are taken for granted, much like theaforementioned roadkill removal worker. Most people enjoy driving towork on a road free from dead animals. When an animal gets run over andleft for dead, the roadkill removal person is dispatched to “dispose”of the remains. When was the last time you sent a “thank you” card toyour roadkill removal person? To that end, when was the last time yousent a “thank you” card to a member of your IT department? Show ofhands?

Now let’s jump back to my original topic with a metaphor: an ITcareer is like a human body and, in order for your career to live along and healthy life, you need a nice thick layer of skin to protectyou from infection. The “infection” in this metaphor referrers to theemotional challenges that every IT professional experiences duringtheir career. In order for IT personnel to adequately quote with thecritical thinking required to overcome most IT related challenges, a“thick skin” is a requirement — one that I believe should show up onmost job postings.

Working on the front lines of an IT organization let’s youexperience what it’s like to sympathize, and empathize, with those whoare having the problems. It lets you develop valuable customer serviceand communications skills while you work towards making the customerhappy. Along the way you’ll have numerous bad experiences which willserve as lessons that you can use to make yourself a better person.

No matter what role you hold within an organization, you havecustomers to answer to. This is something that working the front linesforces you to remember. Good or bad, working in the trenches teachesyou valuable life lessons that will only help you grow as an ITprofessional.

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.

Blind SQL Injection, or passing the elephant through the needle hole

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 casewhen substr(banner, 1, 1) = 'A' then 'u' else 'X' end from (selectbanner from v$version where banner like '%Oracle%')) || 'e

Read the full story here.

Very good PCI resource

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.

Wireshark and SSL connections

I'm maybe a little (a lot?) late on this, but I was reading this nice description of a packet capture analysis from the SANS forensics blog and just found that Wireshark can read SSL encrypted connections if you provide the private key! This is really nice ans useful. Here is a screenshot (also from SANS post) with the screen where you can indicate the private key to be used:

Numbers, numbers, numbers

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.