Yes, I’m reusing this graphic again. Because it’s awesome.

I’ve heard this question come up a couple of times in different forms, “Is Heartbleed a computer virus?” “Is my computer vulnerable to Heartbleed?”

This is often a difficult concept to grasp, which is actually a tribute to how well the internet works most of the time. The internet is meant to feel like there are only two people involved in communication: You and the person (or website) you communicate with.

In reality, there could be any number of participants in the communication getting your communication from you to the recipient. You communicate with your internet provider, who communicates with another provider, who sends the information to the website you want to talk to. The website responds along the same chain.

Any piece of this chain can come under attack. Your computer could be attacked, your information could be stolen as it moves through this chain, the website you’re going to could come under attack.

OpenSSL is a technology used to encrypt traffic between your device and the website you’re visiting (Encryption is a good idea because you’re passing your information to any number of unknown entities to get it to where it’s going. Encrypting it means that only you or the intended recipient can read the information).

So this is not a virus, it’s a flaw in a communication protocol. Like leaving an envelope unsealed when you put it in the mail. In some ways, that’s actually worse than a virus. Anything running OpenSSL with the Heartbeat extension is vulnerable. While this isn’t technically a virus, there are some scenarios where your computer could be attacked. The best course of action is to quickly apply any patch that becomes available for software you use.

NOTE: I say “some scenarios” because the likelihood of someone getting valuable information out of your computer using this, while possible, is low. Webservers that could have dozens or hundreds of people’s data going through them are much more attractive targets.

It sells more movies if you have flashy graphics and pretty pictures. It communicates a “technological fear” in a way that people can relate to. When you see the graph on Q’s screen re-arranging itself and turning red, it looks scary. Or the lab techs in CSI start typing madly on the same keyboard (If you don’t understand why this is ridiculous, try it some time) while windows flash across the screen you feel their horror and confusion over getting “hacked” by some invisible force. It’s an accessible metaphor for hacking.

The truth is that creating all of these fancy graphics during hacking would be as much or more work than the hacking itself. Computers aren’t like people. They don’t flinch and scream when attacked. A lot of these fancy re-arranging graphs are an anthropomorphism for the computer. We can connect to it better emotionally when the computer looks or sounds like it’s reeling under a hacker’s insidious attacks.

In a lot of ways this portrayal of hacking makes it difficult to talk to people about real hacking. The Heartbleed bug is an excellent example of the contrast between Hollywood Hacking and real hacking. There are a number of excellent technical write ups here and here on the bug, but it’s difficult to generate much interest for the public outside of the technical world. At least in part because it’s pretty dry stuff when compared to the Hollywood Hacking in movies.

Rather than flashing cool pictures or making crazy beeping sounds, the server just responds with 0’s and 1’s. The attacker quietly sends an attack to the server, the server quietly responds. There’s much less excitement during, but the impact is incredibly devastating.

Is this a problem? Maybe and maybe not. The people who enjoy hacking movies may not be in the same group as the people who enjoy hacking. But it may be a bit of a rude awakening for future security experts who grew up on Hollywood Hacking in movies and then realize there are far fewer exciting, automatically re-arranging graphs in the real world.

OpenSSL has released a patch for an issue being called the “Heart bleed issue”. There are a couple good technical explanations out there already here and here but I’d like to break it down into basic terms.

You can also just read XKCD

The “heart beat” function is useful for checking if a system is available. Let’s say you’re Facebook and you want to make sure that everything is functioning correctly. You would send the heart beat function a message length and a message that says, “I am alive and ok”. The server replies with that same message: “I am alive and ok.” If you don’t get that exact message back within a specified amount of time there might be a problem with the service and you can set off alarms etc.

As always, nothing is as simple as it seems. The heart beat function also takes a message length. So if you send in “I am alive and ok” you would also send a message length of 17 characters.

Without getting too deep into how computer memory works data is stored by a computer sequentially. So your message “I am alive and ok” gets put into memory next to other data. For this example, the other data is “My password is SeeSpotRun”. So to the computer memory looks like this “I am alive and ok My password is SeeSpotRun”. When the heart beat function responds with the message, it remembers the first character it’s supposed to send and then sends as many characters as the message length you’ve sent in.

With me so far? Here’s where we start exploiting things.

When you send in the correct message length of 17 the heart beat function returns “I am alive and ok” but if you send in a message length of say 32 it would return “I am alive and ok My password is” because “My password is” are the next 15 characters. At this point the attacker is interested and would request more information from memory, say sending in a length of 43 or so to get a message back of “I am alive and ok My password is SeeSpotRun” and now he has your password.

If that isn’t scary enough, remember that other things (credit card numbers, names, addresses, social security card numbers) are stored in memory of a program uses them. If a program is vulnerable it’s pretty much like playing the lottery trying to get something interesting.

Continuing the discussion on Crypto Currency, here’s another issue with using digital dollars: the dollars are indistinguishable.

Let’s say my employer, Payer Inc pays me $500 for the month in 5 $100 bills. I decide to buy groceries and a car. The groceries cost $100, and when I go to buy a car they tell me it will cost $500. At this point, I only have 4 $100 bills, so I can’t get the car.

But in modern times, everything is digital. I don’t get paid with 5 literal $100 bills, Payer Inc sends an electronic message telling my bank, Bank Eville Guys, telling them I have $500 more in my account and Bank Eville Guys adds the money.

What is stopping me from spending that money twice? In theory, when I tell Bank Eville Guys I’ve spent money at a merchant, they should subtract it from my account. I buy $500 of groceries, and I now have $0. But with a name like Eville Guys, they might not do that.

If Bank Eville Guys decides not to subtract that money from my account but creates some currency, I could buy $500 of groceries and then go buy a $500 car. Later on when the grocer, Payer Inc, and the car dealership are having morning coffee, they both comment they thought I only made $500 a month, but they both sold me $500 of stuff. They’re both suspicious, but the only way for them to check on if they’ve been double paid is for them to ask Bank Eville Guys, and of course they’re not going admit to their fraudulent activity.

Again we could mitigate this with good book keeping and perhaps auditing Bank Eville guys on occasion, but we still have a fundamental problem here: without physical dollars to point out our payments are indistinguishable amounts of dollars.

In a previous post I discussed one of the problems with digital dollars being that it’s difficult to monitor currency creation. Here is an explanation of the crypto currency solution to this problem.

The obvious solution is to have some governing body monitor currency and it’s creation, similar to how we do now with having certain facilities that can create paper money. But let’s not be too hasty in our conclusions. Digital money brings a fundamental shift because digital money can be copied very easily. Instead of creating the money physical money you have to keep track of the money that is spent.

In order to truly monitor what money is available for spending and to whom it is available a governing body would have to validate every transaction.

Let’s say we star the system with $1,000. Payer Inc pays me $200 and the governing body validates the transaction. When I try to go buy a car for $400, the dealership asks the governing body if I have the money and it says no, I’m then denied. But if I try to go buy $50 worth of groceries, the governing body validates the transaction because I have $200 total. Once I’ve purchased the groceries, the governing body changes my account value to have $150.

The government may be the obvious solution may be to have the government perform this action but with certain recent revelations about the governments investment in monitoring and mining internet data I doubt many would be comfortable handing their checkbooks over to the federal government for balancing.

So, what can we do?

Here’s a novel idea: what if we make every user of the system a validator of transactions?

Now every user has a ledger (or “general ledger”) that has a record of every transaction ever done in the system. So when I want to buy my groceries, I forward my transaction request to the group. When I have my validation, I can by my groceries.

Now our issue of Bank Connman or Bank Eville Guys creating their own currency goes away because they would have to request validation from every other user of the system and the fraud would be detected.

“But doesn’t that mean all of my spending is now public knowledge?” Good question! And yes, it might. And there is some risk that this ledger could be used for data mining to track individuals and activity. The solution to that issue has been to change the payer and payee from being identified people to being anonymous numbers. Similar to how you know your credit card number but someone knowing your card number may not be able to track you.

This is a simplified explanation of a very involved concept. We need some way of validating transactions, but it would be preferable not to have the government be the sole keeper of that process.

Guardium is a 100% certainty (in theory) database monitoring tool. This means that Guardium will process 100% of the queries that come through a database it is installed on, as opposed to performing sampling on database queries and capturing a percentage of the queries as most other monitoring tools do. Similar to LogRhythm the easiest way to get a picture of Guardium is to talk about how queries travel through Guardium and how they are used.

Guardium uses agents (called STAP agents) that get installed on a database server. These sit on the physical box, outside of SQL Server (or any other database) and are allowed to observe queries as they are sent to the database (Guardium does not block any queries). As a query comes onto the box, Guardium grabs a copy of it and the query is forwarded on to the database itself.

Once the agent has the query, it immediately forwards it on to the collector. The collector runs the policy on the query, which determines what, if any, logging should happen for that query. The logging is limited to information contained in the query, since Guardium has no insight into what happens inside of the database. The collector can then choose to forward the query to the aggregator, which is a feature we aren’t really using right now.

Common things Guardium watches for are privileged user IDs, restricted tables, select *’s, etc. If information about the query is logged it is possible to run reports on it.

Reports are essentially queries written against the data Guardium has logged (who has access what restricted tables, who ran a select *, etc).

These reports can be scheduled as an Audit Process (also called a workflow for simplicity). An audit process is assigned to a specific user and generates reports on a schedule. When a report is generated a user is notified and has to log into Guardium to sign off on the report, verifying that they have seen the results and are not concerned about them.

In some ways Guardium is a SIEM tool for database queries, but without the correlation of sources. It is mostly useful for reports and alarms.

I was at a family gathering recently and over heard a discussion about Bitcoin and a few common misconceptions were brought up. Rather than drag a family party down into the finer points of crypto currency, I decided to address a few of them here. First let’s hit the issue with our current currency.

Counterfeiting is the idea of producing your own currency separate from the source controlling the currency (like the government). With paper dollars and coins we go through a lot of effort to prevent people from being able to create their own currency. But a lot of these measures don’t help prevent electronic counterfeiting. Let’s look at a scenario.

Until pretty recently most people were paid with paper currency that was backed with precious metals. So, my employer, Payer Inc, would give me $500 in bills. I would go to my bank, Bank Good Guys, and give them the bills. Now I have $500 in my account. Figuring out how much money I have in my account is pretty easy: just look at how many bills are sitting in the box with my name in it (I realize I’m oversimplifying banking. I apologize to any bankers out there).

Simple, right? Now let’s use computers to make it way more complicated.

Now a lot of banking is done electronically. Rather than hand me paper bills, Payer Inc has an account with Bank Connman and I have an account with Bank Eville Guys. To pay me, Payer Inc sends electronic messages to Bank Connman telling them they’re going to send $500 to Bank Eville Guys to pay my pay check and another message to Bank Eville Guys letting them know I’m being paid. Bank Connman subtracts $500 from the amount in Payer Inc’s account, and Bank Eville Guys adds $500 to my account.

What if these banks are true to their names? Perhaps Bank Connman isn’t too happy to lose those $500 because it makes their total value go down, so even though they tell Bank Eville Guys I’m being paid $500, they only subtract $400 from Payer Inc’s account. Bank Eville Guys decides that it’s better for their own interests if I get paid $1,000 because it makes their average customer salary go up.

They’ve both just created currency. Unlike paper bills, there’s no finite number of specially marked pieces of paper that limit the amount of currency in circulation. There’s just 0’s and 1’s that can be changed more or less at will.

We’ve mitigated a lot of this with good book keeping. Payer Inc audits Bank Connman, Bank Connman audits Bank Eville Guys, the government audits everybody, you know the drill. But the fundamental difficulty is still there: It is very difficult to track dollars when they are not tied to paper bills. In a lot of ways mutual desire for the currency system to keep working is probably a good defense here. The banks want consumers to trust currency and consumers trust currency as long as no one takes advantage of it.

IPS (Intrusion Prevention System) and IDS (Intrustion Detection System) both use technology that watches internet traffic and looks for attacks or intrusions using signatures and does some action based on any signatures the traffic matches. An IPS has the ability to block traffic that it considers suspicious, while an IDS only has traffic mirrored to it and cannot prevent any traffic from reaching it’s destination.

A good analogy for IDS/IPS is a spam email detector. The spam detector looks at your email before you receive it and looks for patterns or words that usually mean the email is a spam message (I’ll let you infer common spam email subjects here). If it sees one it is confident is spam, it puts it in your spam folder and doesn’t tell you. If it sees a message that could be spam, but could also be legitimate email (your friend offering to sell you a car) it might mark it as potential spam, but still deliver it to your inbox).

For the IDS/IPS technology the signatures are looking at packets and protocols instead of words (Not sure what your familiarity is with internet and network protocols, let me know if you have questions there). Some good examples of things IPS looks for can be found in the IPS Weekly Reporting (one is here for reference).

Threats on the internet are changing constantly, so whenever the IPS vendor releases a new version of their signatures we download and apply it. This allows our IPS, which is older, to look for threats that have only been released very recently, similar to how a virus scanner can find new viruses.

SIEM is really the business of looking for anomalies in data. Let’s say we track your computer’s login activity for a month and you log on to your computer daily at 8 am and 12:30 pm (when you arrive for the day and when you get back from lunch). Then suddenly and without warning we see your ID active at 3 am. That’s an interesting anomaly.

Going a level higher (and more mature in most definitions) let’s say we also track your email login activity. Every day when you log in to your computer you also log into email and check your messages. So everyday at 8 am we see a computer login and then an email login. But then at 3 am we don’t see an email login. Now we’re extra suspicious of the 3 am activity because it doesn’t follow your normal behavior.

This is a simply example, but I’m sure you can see how we could get really creative with this and tie behavior of different systems together. This is why an academic version of SIEM pushes for all of the data to be in one tool. It would be very difficult for a human to watch all of these different log sources for abnormal behavior. If you have all of this data in one tool you can automate the sequence of events and then generate alarms or alerts based on what the automated process detects.

When implemented this can still require human contact. For our example, when you logged on at 3 am, you were probably just awake and wanted to get some work done that didn’t require email. So when an alert is generated, it goes to a SIEM analyst and he does a quick investigation, notices that all of your web traffic looked normal (to google.com and espn.com), and nothing else suspicious was going on. He marks it uninteresting and moves on. But if you had gone to known malicious websites, he would assume an attack had gained access to your computer and would escalate it to the next level to be researched.

After the researcher realizes that what websites you go to could be checked after noticing your computer is logged into and your notes is opened, he could add that to the alarm process and tell the alarm not to fire if no suspicious web traffic is detected (this last part is called tuning).

The premise is that normal employee behavior is consistent and steady over time, while an attack will look abnormal when compared to that typical employee behavior.