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.

Yet another system summary I did for management (I’ve been pumping them out like jelly beans lately).

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.