Thursday, September 20, 2007

The Hen House Has a Fox Guarding It!

I've been seeing these interesting issues crop up lately and it's bugging me, so I've decided to write about it. Well, OK, not so much write but more rant a little bit. Hey - everyone needs to vent sometimes.

What I'm particularly miffed about is this idea of self-assessments for policy policing. Here's a scenario-

Company A is PCI certified (yes, I'm beating the PCI horse again because it's so easy...) and demands that all its partners and vendors be the same. This is fine, and quite honestly very responsible. The problem is in the execution. Normally - when I want to validate something, I go do it, or pay someone to do it for me if I'm too busy. [This is where self-assessments drive me nuts.] Company A now sends a requirement to Partner B to be compliant with whatever PCI regulations exist, and sends along this questionnaire for Partner B to self-assess their company against requirements.

This drives me insane because I've seen time after time requirements be "creatively answered"... let me explain. A requirement may be that all PII (personally identifiable information) is encrypted while at rest. To me that means database encryption, and encryption anywhere data "sits" at rest. Partner B looks at their network and says to themselves, "Gee, we don't encrypt databases 100%, but yea, sure, we encrypt flat files and most of our databases, so sure, check!" Now, if I've got someone auditing Partner B, they fail. If Partner B self-assesses and checks the box, no one is there to call them on it.

But what's the problem, you say? The ownership of a breach lies squarely on Partner B when someone breaks into their systems and steals tons of data, right? This is where you pull out your piece of paper that they self-assessed and say "but they said they were compliant!" That's nice in the legal world - but in the court of public opinion you're no less screwed then you would be if this was a gaff on your own part.

Self-assessments are a joke because there are so many times I've seen (and a few times I've been asked to participate in) "creative answers" to these self-assessment questions. When an auditor shows up it's black or white - you're either compliant or you're not. Of course, the topic of auditor subjectivity is another rant for another day.

My point is this folks, if you're serious about the security of your partners, don't ask them to fill out questionnaires and assume they're being honest with you. People lie. And it gets worse when a company is less-than-prepared to do business on a high-security plane and is presented with a big opportunity. They will lie to you. Don't trust them. Have we lost this mentality? What happened to trust but verify?

Keeping a paranoid mentality, and assuming human nature holds and people lie will save your assets, and just maybe it'll save that nice space on the front and center of the Wall Street Journal for your competitor.

Good luck.

Wednesday, September 19, 2007

Policies and Enforcement in the Real World [or, how not to be a speedbump]

I've spent several years working for companies big and small, and have this interesting view on the past 10+ years of experience in IT. I've been lambasted in the recent past for being a bit of a cynic on policy where there is no teeth - so I feel the need to explain my position a little bit. Just maybe you'll sympathize and "get me"...

There are 3 "tiers" of corporations out there with respect to policy as it relates to IT Security, in my humble opinion. They are as follows

  • Anarchy (30%): A complete disarray. These types of companies may have a policy or two but they are likely incoherent, poorly distributed, and broadly ignored. These are companies that grow too quickly, disregard their IT departments, and abuse their technologies - these folks have two options - move up a tier or brace for disaster. One of the two will happen.
  • Law (60%): This tier is where, I hope, most companies find themselves. You have policies, they may even be well-written, well-defined, cover all your base risks, and are distributed well amongst your population of employees and relevant users. Your problem is that you can't enforce these policies.
  • Order (10%): If you find yourself in this tier, consider yourself very lucky. Companies in this tier not only are well documented and distributed on their policies, but someone actually enforces them. The difference between having something and having something that's enforecable is here at this tier. This is a very select population of companies, and you'd be surprised to know it's rare to find them in the "enterprise" class of companies.

My point - the buzz-word in the IT Security world as it relates to upper management has been policy in the last several years. Yes we all have these "cool" technologies we implement and some of us even draft up acceptable use documentation and guidelines; some of us call these policies and put them in bound and glossy folders and give them away to our users. That's all well and good but what happens when someone challenges your policy? What happens when your policy says that non-company assets are not allowed to be plugged into your network; but a middle-manager has an army of consultants which come in and insist on plugging in their laptops to do whatever it is they were commissioned to do? Ask yourself this question and the oft-given answer is -- the need to conduct business will win ever time and the policy will be ignored (at least temporarily) So what is the point of the policy? Remember, that one 'exception' will quickly become the accepted standard as general users watch the policy be subverted. So regardless of what your policy says, a few weeks later everyone is having random visitors plugging in their laptops into your network. What went wrong?

I would argue that the problem was not with your policy, but with the "teeth" behind it. What should have happened, was that rather than simply saying "you've being over-ridden in the name of business" the manager wanting to subvert policy should have needed to escalate the matter. The matter should have reached the CISO, or maybe even the CIO - and that's where you should have had your backing. The CIO should have heard the argument, and made an assessment as follows:

  • The policy exists for a reason and it's the accepted standard (law) in the company and cannot be subverted
  • An alternative is to provide the consultants with resources to use for the time they are on your network -OR-
  • The consultants should have their machines somehow vetted by the security team, and an ammendment is made to the policy to provision for this type of requirement going forward

What would your CIO do if faced with this situation? Do your policies have teeth? I will offer you (from my experience) one method of giving your policies teeth. I will dispense my formula to you, which you can use at your own will - I make no guarantees this will work for you, but will tell you that it's worked for me in the past.

  • Never develop a policy in a vacuum; consider business requirements and non-IT factors (such as the consultant example above) that may complicate your execution of the policy you're writing
  • Write a policy that's straightforward - the shorter the better honestly. Number your sections, lay it out logically, and proof-read it for logic problems and contradictions.
  • Give it to your grandmother, wife, or anyone that doesn't work in IT. Ask them if they understand it, and what challenges to productivity they can find in it (trust me on this one... this is a gem)
  • Give it to your marketing or communications team. If you don't have one of these, find a PR firm, pay a small fee and have your policy "polished" for user-friendliness and effectiveness.
  • Receive approvals in steps -start with local managers, and work your way up to the CIO. When you reach your CIO's office, you can show how you've done your homework and that people below the CIO agree with your policy, that it's user-friendly, and that you "understand the business needs" while trying to enforce security policy
  • Ask for the ability to enforce the rules you've set forth. Have a conversaion with your CIO, and this is a tough one, about how policies will be enforced. Ask what penalties there will be, and what actions will be taken on escalations, etc. Do not let this go.
  • Market the policy to your users. Make it fun for people to read/understand what the policy is... have a contest to see who can answer the most questions correctly on a quiz which roots its answers in the policy. Offer some trinket or chachkie to your users who do the best job -- incent your users to read your policy.
  • When a chance comes up to enforce the policy, always play the understandig role first and foremost. Never give the answer "well you can't do it, period, because the policy says so" - you'll lose the escalation to the CIO, almost guaranteed. Try to understand the need, offer suggestions, and document this for further escalation or compromise.
  • When you need to, pull out the big bat, and make sure you pick your battles wisely. Don't squabble and run to your CIO with every little violation - try and handle your own playground. Yuo don't always want to run to mommy every time your pride is hurt.
  • Overall, enforce policy consistently, fairly, and with a gentle ear and a firm hand.

Good luck out there.

Wednesday, September 12, 2007

Quick ZFS nerd humor

As I was reading a little more about ZFS for a project today, I came across this Wikipedia entry, which I thought was humorous in a nerdy sort of way - and I figured you readers would enjoy if you haven't seen it yet. We've all heard the term "boil the ocean" but this takes it to a whole new level: (quoted directly from Wikipedia here...)

Project leader Bonwick said, "Populating 128-bit file systems would exceed the quantum limits of earth-based storage. You couldn't fill a 128-bit storage pool without boiling the oceans."[1] Later he clarified:

Although we'd all like Moore's Law to continue forever, quantum mechanicskilogram of matter confined to 1 liter of space can perform at most 1051 operations per second on at most 1031 bits of information [see Seth Lloyd, "Ultimate physical limits to computation." Nature 406, 1047-1054 (2000)]. A fully populated 128-bit storage pool would contain 2128 blocks = 2137 bytes = 2140 bits; therefore the minimum mass required to hold the bits would be (2140 bits) / (1031 bits/kg) = 136 billion kg. imposes some fundamental limits on the computation rate and information capacity of any physical device. In particular, it has been shown that 1

To operate at the 1031 bits/kg limit, however, the entire mass of the computer must be in the form of pure energy. By E=mc², the rest energy of 136 billion kg is 1.2x1028 J. The mass of the oceans is about 1.4x1021 kg. It takes about 4,000 J to raise the temperature of 1 kg of water by 1 degree Celsius, and thus about 400,000 J to heat 1 kg of water from freezing to boiling. The latent heat of vaporization adds another 2 million J/kg. Thus the energy required to boil the oceans is about 2.4x106 J/kg * 1.4x1021 kg = 3.4x1027 J. Thus, fully populating a 128-bit storage pool would, literally, require more energy than boiling the oceans.[5]

Tuesday, September 11, 2007

What I learned... Part 1

The lights are out, the vendors are gone, the guest speakers and panels are silent... the conference is over. Now it's time to share what I've learned in the hopes that it will benefit you, my readers, and make us all better people.

So without further ado, here's the first and most important thing I've learned - We're going about this security issue all wrong! Before you hit the comment button to tell me just how wrong I am, keep reading.

In the last 2 days I heard some amazing stories about how people have gotten bigger budgets, patched faster, tested better, and secured more. What I absolutely did not hear is how much risk was avoided, mitigated or eliminated. None. Process that.

What I can honestly say is that we as security professionals solve problems as we see them. Remember the old addage, if you're holding a hammer, everything looks like a nail? This is so true in IT Security. We're approaching everything with our IT backgrounds, with our security hats on. Things are black and white, right or wrong, we either have a good practice or we don't. There is no gray area. Wrong.

If it's one thing that I think should have been driven home more than it was, it's that security is not black and white. It's all gray. It's not a matter of solving a problem. You're never going to "secure the end-user" or "secure a server"... unless you've cut the power and all other cords and encased it in concrete, then wiped the disks and all IP is eradicated. What we as security professionals should be striving to do, in order to function as an extension of the business, is lower/mitigate risk. If you've heard this already, and I'm preaching to the choir you can stop reading. If this is a new idea to you and the first time you're hearing it it's time to wake up. The last time we as security pros "solved" a problem was... well... when was it? Let me take a few examples and discuss the "measures we have taken" and how they have absolutely not solved the problem.

First up are viruses, on everyone's list since the early 90's.
  • The problem: viruses are constantly out there to destroy productivity and destroy the machine, steal data, or other malicious activity
  • Our solution: Anti-virus software on all laptops, desktops, servers
  • Why we failed: Quite honestly, viruses still exist, they still infect machines. Yes it's true they aren't as nasty as they were since we've put virus detection and remediation software in place, but viruses have only morphed into different forms, and continue to attack our systems. We haven't "eliminated the virus threat".
  • The risk-based approach/view: Due to the introduction of virus mitigation systems software on our systems, viruses are a controllable threat which is now for the most part effectively minimized as a threat. The key is that the threat is minimized and not eliminated.
Based on this example we should be able to apply the same principle to any number of business-problems. Try not to be holding a hammer. Let me take another example, and walk us through a risk-based approach, with a real-world example.

Let's make up a country, call it Elbonia (from Dilbert land). Elbonia has a population which has not yet been exposed to credit cards and credit like we have been in the US and is thus an emerging market for credit products. Elbonia has a store chain, called Elbonia-Mart which sells everything from watermelons to widgets, and wants to partner with a vendor to come in and offer credit so that Elbonia-Mart's users can afford to purchase some of the bigger-ticket items on credit such as televisions. Keep in mind these facts: Elbonia has no credit reporting agencies, no good way to track users identities like the US Social Security System (although that is arguably flawed), and Elbonia is ultra-low-cost when it comes to implementing solutions. You are now faced with a problem. Credit card applications are being processed on a computer which is set up on a 56k DSL VPN to the corporate DMZ for credit decisioning online, the terminal then prints out the application and "temporary shopping pass" when a user is approved for credit. The problem is, these terminals are not up-to-date on personal firewall, virus protection, or patches so they are out of compliance with the corporate standard the vendor (your employer) has set out. What do you do, what problem do you solve and how?

If you're like a very large percentage of people in our industry - you immediately start to solve the issue of patches, personal firewall and anti-virus updates to these low-bandwidth relatively insecure PCs. You fail to do a proper risk assessment and your efforts fail. I'll explain why even if you do manage to get these machines "secured" to corporate standards without over-spending you've failed.

Re-read the section above where I discussed the parameters of Elbonia. There is no credit agency, there are no national identities. While the first thing we think of is to protect the terminal against identity theft and data theft think again. Why would I, as an organized criminal, attack the terminal to steal someone's identity? I can just as easily make one up! Furthermore, why not just walk by and pick up the stack of printed applications (paper is our enemy) which are there when the sales guy is distracted? These two methods will immediately circumvent whatever digital security measures you've put in place, if you went that way. A proper risk assessment would have told you that (a) identity theft is not a problem, and therefore not something to deal with in the immediate future, and (b) paper should be eliminated quickly too! After doing a proper risk assessment, you would may very well have simply decided to take the relatively simple step to either eliminate or secure the paper copies, and call the project done and monitor further for other signs of malicious activity. You've just saved your business money - and what's better, you've proven to your business people that you understand what the real threat is.

In a nutshell, this is the most important take-away from this conference. We're solving problems without fully understanding the situations, without fully analyzing the situation from all sides, and in an "IT vacuum"... that is, without talking or understanding the business model and drivers behind these issues.

The lesson? Known the risks. Understand the full threat. Talk to your business and understand that security is not black and white... it's [your] gray matter that makes it work.

Monday, September 10, 2007

Update: Exciting stuff

Hello readers... I'm attending an event this week (Monday and Tuesday) called "The Security Standard" with lots of executive panels and speakers on IT Security from all over the indutry. Lots of vendors as well, so I'll be posting lots of interesting new topics... here's a taste to get Pavlov's theory going...

Upcoming Topics
  • Toothless Regulations
  • The Politics of Data Breaches
  • The Fraud-sniffing Dogs of War
  • Compliance Nonsense
  • Auditors - Friend or Foe?
  • ...and more as the conference unravels! Stay tuned.

Friday, September 7, 2007

Applying real-life principles to technology

It's amazing how much we in technology don't learn from our counterparts in the physical world. Let us take, for example, banks. The physical bank is built to withstand significant attack. Even if we look back a hundred years, banks were built with vaults, gates, and other protection mechanisms. So ask yourself why we don't apply that same principle to securing our 'digital' assets... our data-stores. I'm going to analyze for everyone's benefit the points that the digital can take from the physical. I'd dive into why we don't take the queue from the physical security folks - but that turns into a bit of a philosophical rant (which I will admit, I will write about at least a little).

So let's take a would-be bank robber's point of view into a bank. Pick a bank, any bank really, and you'll notice that going outside in you will encounter the following things:
  1. proper site planning to keep the getaway (escape route) as complex and difficult as possible
  2. well fortified structure of the building
  3. surveillance cameras
  4. armed guards at the entry
  5. properly separated internal chamber of the building (separated entryway from bank main lobby)
  6. properly separated and secured teller stations (where the cash, at least some of it, is)
  7. properly separated back office
  8. silent alarm triggers strategically placed where the tells can reach without being spotted
  9. outer vault door locked by a key held by bank manager or designee
  10. highly fortified, hardened outer vault door
  11. separated inner vault (with all the trimmings such as hardened steel, etc)
  12. non-descript inner-vault chamber compartments
  13. tagged (booby trapped) loot in case it's stolen to help track it and identify the thieves
Now, I'm no banking security expert, so these thirteen (13) things are just ones that I have observed with the naked eye when in a bank, and from a tour I was privileged to get. That's a lot of theft deterrent! Are we applying the same principles to securing our digital assets? I can say with a high degree of accuracy that a vast majority of the corporations out there don't protect their digital assets nearly as well. Now, there may be reasons such as your data not being of as much value, or simply not knowing where the digital assets are which need to be protected -- but that's absolutely no reason to weasel out of it.
I will analyze the above thirteen (13) observed physical security measures of a bank, and parallel them with digital or 'cyber' security technologies. The numbers above will match up to the digital equivalent in the analysis below, so pay attention.

  1. system design to disallow easy exit with stolen data
    • a system which disallows servers to initiate communications to the Internet; if a cracker breaks into your server, forces a shell, and wants to ftp the stolen data somewhere off the system your network firewall had better disallow that!
  2. hard outer perimeter
    • firewall rules limiting exposure of internal servers, networks, and users; properly configured access lists or firewall rules to allow only absolutely necessary exposure of services to the outside world
  3. digital surveillance at the perimeter
    • at least an IPS to filter for anomalous traffic patterns, or at very last pattern-based filtering and alerting (with blocking) mechanisms... some way to notify the security operations team something is wrong
  4. enforcement points at your outer points
    • IPS at your perimeter, NAC controls to keep just anyone from plugging in and rummaging around... these are the very very basics
  5. separation of services (a la DMZ, or zones)
    • (see #7)
  6. separation of services (see above)
    • (see #7)
  7. separation of services (see a pattern here?)
    • DMZs, containers, or whatever you'd like to call them; compartmentalize, segregate and filter access into different segments or zones on your network. Servers accessible to users should be on a separate network segment from servers used by administrators for all-access to out-of-band management, which should be kept separate from router and switch networks... segregate, segregate, segregate
  8. internal processes to notify security of a potential issue before it becomes a breech
    • workflows, ticketing systems, "response team" phone numbers... anything which can give users who see suspicious activity on your network a simple way of contacting your security operations team
  9. separation of privileges on digital systems (least-privilege model, with master-key kept secret)
    • separate data administrators from data users; the database administrator should have no reason to read the user_full_info table in its entirety, only administer rights to that database, table, etc; take away all privileges which are not explicitly required to perform work function!
  10. separated server networks
    • separated (logically at least, physically and logically at best) subnets and containers for servers, away from subnets for general users; these of course should be firewalled and have an IDS/IPS at the gateway into and out of them
  11. separated server farms acting as data containers
    • containers for databases, file-servers, and other sensitive servers which are kept well guarded and away from being accessible by the general public via firewall rules and anomaly detection devices such as an IPS
  12. non-identifiably labeled asset tags
    • server labels which look more like USSRVWIN0001A and less like FINANCE_FILESERVER to keep potential thieves guessing and grasping while your detection mechanisms work their magic
  13. false data to trigger alerts if/when used outside the organization
    • fraud teams and credit bureaus create 'fake identities' which look perfectly real and indistinguishable from others in the system, that when used trigger a fraud alert... brilliant!
Now, the sad fact here is that as security professionals we haven't really learned much (or haven't applied it, if you prefer) to the digital world. Why? There are a myriad of excuses including poor budgets, poor management, inability to execute or affect change... but whatever your excuse it's exactly that, an excuse. We as IT pros should learn from the physical nature of the world, and how protected storage is done in 'real life'. If you don't like my bank vault example, use an old medieval castle - same concepts! You'll see that the same principles have been applied for hundreds of years in the application of physical security. Let's hope it doesn't take us that long to figure it out in the IT world...

Good luck.