Before we delve into the intricacies of individual methods of anti-debugging let’s use this post to define the classes of anti-debugging that we will be discussing. While other classes may exist, the definition of these classes is an attempt to include the majority of anti-debugging methods in use today. There is some overlap between classifications and we may have left out some methods due to limited exposure or effectiveness.

API Based Anti-Debugging
API based anti-debugging is the most straightforward and possibly the easiest to understand for a typical developer. Using both documented and undocumented API calls, these methods query process and system information to determine the existence or operation of a debugger. From single line calls such as IsDebuggerPresent() and CheckRemoteDebugger() to slightly more complex methods including debugger detaching and CloseHandle() checks. These methods are generally trivial to add to an existing code base and many can even be implemented in as few as two or three lines.

Exception Based Anti-Debugging
Exception based anti-debugging is slightly different than your basic API based techniques. Many times when a debugger is attached to a process, exceptions are trapped and handled by the debugger without regard to passing the exception back to the application for continued execution. Occasionally these exceptions can even crash or terminate a process when run under a debugger and be handled gracefully when running clean. It is these discrepancies that makes exception based anti-debugging techniques possible.

Process and Thread Block Anti-Debugging
Some of the API based anti-debugging methods use published functions to query information from within the process and thread blocks for our running code. Many API based detections can be subverted within a debugger by hooking the API call and returning values that indicate a clean process. One way around this subversion is to directly query the process and thread blocks, bypassing the API calls. Direct analysis of the process and thread blocks, while more complex, can lead to a more accurate and high assurance result.

Modified Code Anti-Debugging
One of the methods that a debugger uses to signal a breakpoint is to insert a break byte into the running code at the location that it wishes to stop execution. The process execution breaks when this value is seen, giving control to the debugger. When the program is resumed, the breakpoint value is removed and replaced with the original byte, the execution backed up one byte, and the program is resumed. Detection of software based breakpoints can be achieved by analyzing the process for modifications from the expected norm.

Hardware and Register Based Anti-Debugging
A second way that a debugger can break the execution of a process is by using a hardware breakpoint. A hardware breakpoint relies upon CPU registers to store the pertinent information and to detect when the target break addresses are seen on the bus. A break interrupt is triggered at the appropriate time based on these register values. Reading or modifying the hardware can allow for the detection of a debugger.

Timing and Latency Anti-Debugging
Finally timing and latency can be used as an effective anti-debugging method. When executing a program within a debugger, specifically when single stepping, a much larger latency occurs between execution of instructions. This latency can be detected and compared against a reasonable threshold to detect the existence of a debugger attached to our process.

Each of the classes of anti-debugging outlined above has merit when used individually to protect a process. While none of them can be assured to ever protect a program from a determined reverse engineer or debugger, implementation of these techniques (or many of them if appropriate) can sufficiently slow down the debugging process and hopefully make the attacker spend his time on other, easier, ventures. In the remainder of this series on anti-debugging we will review in depth some of the more interesting methods of each of the above classes. So bring along your debugger and your development environment and let the games begin.

Errata: Version 1.1 of the paper, reference, and optimized code corrects an error in which the length of the configuration string was passed in as the size of the internal block (256 bits for Skein-256, 512 for Skein-512, and 1024 for Skein-1024), instead of a constant 256 bits for all three sizes. This error has no cryptographic significance, but affected the test vectors and the initialization values. The revised code also fixes a bug in the MAC mode key processing. This bug does not affect the NIST submission in any way.

NIST has received 64 submissions. (This article interviews one of the submitters, who is fifteen.) Of those, 28 are public and six have been broken. NIST is going through the submissions right now, making sure they are complete and proper. Their goal is to publish the accepted submissions by the end of the month, in advance of the Third Cryptographic Hash Workshop to be held in Belgium right after FSE in February. They expect to quickly make a first cut of algorithms -- hopefully to about a dozen -- and then give the community about a year of cryptanalysis before making a second cut in 2010.

Lastly, this is a really nice article on Skein.

These submissions make some accommodation to the Core 2 processor. They operate in "little-endian" mode (a quirk of the Intel-like processors that reads some bytes in reverse order). They also allow a large file to be broken into chunks to split the work across multiple processors.

However, virtually all of the contest submissions share the performance problem mentioned above. The logic they use won't optimally fit within the constraints of a Intel Core 2 processor. Most will perform as bad or worse than the existing SHA-1 algorithm.

One exception to this is Skein, created by several well-known cryptographers and noted pundit Bruce Schneier. It was designed specifically to exploit all three of the Core 2 execution units and to run at a full 64-bits. This gives it roughly four to 10 times the logic density of competing submissions.

This is what I meant by the Matrix quote above. They didn't bend the spoon; they bent the crypto algorithm. They moved the logic operations around in a way that wouldn't weaken the crypto, but would strengthen its speed on the Intel Core 2.

In their paper (PDF), the authors of Skein express surprise that a custom silicon ASIC implementation is not any faster than the software implementation. They shouldn't be surprised. Every time you can redefine a problem to run optimally in software, you will reach the same speeds you get with optimized ASIC hardware. The reason software has a reputation of being slow is because people don't redefine the original problem.

That's exactly what we were trying to do.

Things are so bad in China that its gross domestic product growth rate may fall from double digits to the dowdy level of 8%. Eight percent, by the way, is a level at which the United States is unlikely to ever grow again. It can't. Our economy is simply fully developed. Thus the sobriquet "developed economy." I know, not exactly catchy.

..

All of the headlines show China sitting at a crossroads. But the reason I have faith in China is that it has historical proxies. Since 1970, with the exception of a few OPEC members, only four economies have made the transition from emerging to developed markets (meaning their per-capita incomes exceed $15,000 per year): Taiwan, Singapore, Hong Kong, and South Korea.

These four economies have two things in common. First, they have few natural resources; and second, they are dominated by Chinese values and the traditional Chinese work ethic. Mainland China is different only because it got a later start.

“When I wrote the book, I thought I was writing about the future. When it was going to press, I thought it was about current affairs. Now I wish it was about history.”

This part below reminds me a lot of 1995 security architectures used to defend 2008 integrated applications

The present crisis had been triggered because the international financial system had undertaken activities that had “far outpaced the ability of the infrastructure to sustain them”, said El-Erian.

And it was not just the markets that could not cope with their own changes, but governments as well. Significant weaknesses had been exposed “from the firms, to the regulatory agencies, to governments, to multilateral oversight”.

“Turbocharge that with financial innovations, which history tells us we tend to overproduce and overconsume, and it’s inevitable that you will get a series of market accidents,” he said.

One easy, inexpensive way to actually increase your effectiveness in 2009 is to, right now, make a quick review your risk management processes.  As you take a look at how you’re using risk in your organization, I’d ask you to make sure that those processes are providing value for the energy you’re spending.  If they’re not - if you’re not successfully using risk within security and with the other lines of business that you serve - then I’d like to invite you to  come take advantage of RMI’s public training session for 2008, held in Columbus Ohio on December 10-12.  >A brochure is here<.

For three days and $1,995 - you’ll get real answers to many of the commonly voiced frustrations RMI hears concerning risk & risk management.  Answers around measurement, application, communicating risk to other lines of business, heck, basic answers as to what risk is and how to get consistent, defensible values that actually mean something.

Not to mention - Strengthening your Risk Management processes increases your ability to manage risk, which reduces the amount of risk you actually face.

NEW TO THE PUBLIC STUFF!

I’m personally excited because this is the first time that our public training we’ll feature measurement “calibration” exercises and include excel tools to take home and use for quantitative FAIR analysis.  These are benefits we’ve only previously reserved for private client workshops.

I know that FAIR can help you and your organization, but as the sales guys always say, “don’t take my word for it”.  Here’s something we recently received (unsolicited) from the CSO of one of the 10 largest banks in the US, who has had several of his analysts receive this same basic training:

I would like to also add my deep appreciation for what FAIR and RMI has brought to (us) and how we go about the business of risk analysis. We have had some great conversations around risk with the lines of business that have ended very favorably for us.

More information can be found on RMI’s website here:  http://www.riskmanagementinsight.com/12_2008_training.html

Thanks.

Oh and tomorrow, we’ll talk a little bit about quantitative and qualitative risk.

District Court Holds that Running Hash Values on Computer Is A Search: The case is United States v. Crist, 2008 WL 4682806 (M.D.Pa. October 22 2008) (Kane, C.J.). It's a child pornography case involving a warrantless search that raises a very interesting and important question of first impression: Is running a hash a Fourth Amendment search? (For background on what a "hash" is and why it matters, see here).

First, the facts. Crist is behind on his rent payments, and his landlord starts to evict him by hiring Sell to remove Crist's belongings and throw them away. Sell comes a cross Crist's computer, and he hands over the computer to his friend Hipple who he knows is looking for a computer. Hipple starts to look through the files, and he comes across child pornography: Hipple freaks out and calls the police. The police then conduct a warrantless forensic examination of the computer:

In the forensic examination, Agent Buckwash used the following procedure. First, Agent Buckwash created an "MD5 hash value" of Crist's hard drive. An MD5 hash value is a unique alphanumeric representation of the data, a sort of "fingerprint" or "digital DNA." When creating the hash value, Agent Buckwash used a "software write protect" in order to ensure that "nothing can be written to that hard drive." Supp. Tr. 88. Next, he ran a virus scan, during which he identified three relatively innocuous viruses. After that, he created an "image," or exact copy, of all the data on Crist's hard drive.

Agent Buckwash then opened up the image (not the actual hard drive) in a software program called EnCase, which is the principal tool in the analysis. He explained that EnCase does not access the hard drive in the traditional manner, i.e., through the computer's operating system. Rather, EnCase "reads the hard drive itself." Supp. Tr. 102. In other words, it reads every file-bit by bit, cluster by cluster-and creates a index of the files contained on the hard drive. EnCase can, therefore, bypass user-defined passwords, "break down complex file structures for examination," and recover "deleted" files as long as those files have not been written over. Supp. Tr. 102-03.

Once in EnCase, Agent Buckwash ran a "hash value and signature analysis on all of the files on the hard drive." Supp. Tr. 89. In doing so, he was able to "ingerprint" each file in the computer. Once he generated hash values of the files, he compared those hash values to the hash values of files that are known or suspected to contain child pornography. Agent Buckwash discovered five videos containing known child pornography. Attachment 5. He discovered 171 videos containing suspected child pornography.

One of the interesting questions here is whether the search that resulted was within the scope of Hipple's private search; different courts have approached this question differently. But for now the most interesting question is whether running the hash was a Fourth Amendment search. The Court concluded that it was, and that the evidence of child pornography discovered had to be suppressed:

The Government argues that no search occurred in running the EnCase program because the agents "didn't look at any files, they simply accessed the computer." 2d Supp. Tr. 16. The Court rejects this view and finds that the "running of hash values" is a search protected by the Fourth Amendment.

Computers are composed of many compartments, among them a "hard drive," which in turn is composed of many "platters," or disks. To derive the hash values of Crist's computer, the Government physically removed the hard drive from the computer, created a duplicate image of the hard drive without physically invading it, and applied the EnCase program to each compartment, disk, file, folder, and bit.2d Supp. Tr. 18-19. By subjecting the entire computer to a hash value analysis-every file, internet history, picture, and "buddy list" became available for Government review. Such examination constitutes a search.

I think this is generally a correct result: See my article Searches and Seizures in a Digital World, 119 Harv. L. Rev. 531 (2005), for the details. Still, given the lack of analysis here it's somewhat hard to know what to make of the decision. Which stage was the search — the creating the duplicate? The running of the hash? It's not really clear. I don't think it matters very much to this case, because the agent who got the positive hit on the hashes didn't then get a warrant. Instead, he immediately switched over to the EnCase "gallery view" function to see the images, which seems to be to be undoudtedly a search. Still, it's a really interesting question.

Warnings About Financial Institutions and Derivatives

Risks of Financial Institutions
The nature of a financial institution is that there are a lot of ways to go to hell in a bucket. You can push credit too far, do a dumb acquisition, leverage yourself excessively---its not just derivatives [that can bring about your downfall].

Maybe it's unique to us, but we're quite sensitive to financial risks. Financial institutions make us nervous when they're trying to do well.

We're exceptionally goosey of leveraged financial institutions. If they start talking about how good their risk management is, it makes us nervous.

We fret way earlier than other people. We've left a lot of money on the table through early fretting. It's the way we are -- you'll just have to live with it.

Derivatives
The system is almost insanely irresponsible. and what people think are fixes aren't realy fixes. It's so complicated I can't do it justice here - but you can't believe the trillions of dollars involved. You can't believe the complexity. You can't believe how difficult it is to do the accounting. You can't believe how big the incentives are to have wishful thinking about values and wishful thinking about ability to clear.

People don't think about the consequences of the consequences. People start by trying to hedge against interest rate changes, which is very difficult and complicated. Then, the hedges make the [reported profits] lumpy. So they use the new derivatives to smooth this. Well, now you've morphed into lying. This turns into a Mad Hatter's Tea Party. This happens to vast, sophisticated corporations.

Somebody has to step in and say, "We're not going to do it - it's just too hard."

I think a good litmus test of the mental and moral quality at any large institutions [with significant derivative exposure] would be to ask them, "Do you really understand your derivatives book?" Anyone who says yes is either crazy or lying.

It's easy to see [the dangers] when you talk about [what happened with] the energy derivatives - they went kerflooey. When [the companies] reached for the assets that were on their books, the money wasn't there. When it comes to financial assets, we haven't had any such denouement and the accountings hasn't changed so the denouement is ahead of us.

Derivatives are full of clauses that say if one party's credit gets downgraded then it has to put up collateral. It's like margin - you can go broke [just putting up more margin]. In an attempt to protect themselves, they've introduced instability. Nobody seems to recognize what a disaster of a system they've created. It's a demented system. 

In engineering people have a big margin of safety. But in the financial world, people don't give a damn about safety. They let it balloon and balloon and balloon. It's aided by false accounting. I'm more pessimistic about this than Warren is.

Accounting for Derivatives
I hate with a passion GAAP [Generally Accepted Accounting Principles] as applied to derivatives and swaps. JP Morgan sold out to this type of accounting to front-end revenues. I think it's a disgrace.

It's bonkers, and the accountants sold out. Everyone caved, adopted loose [accounting] standards, and created exotic derivatives linked to theoretical models. As a result, all kinds of earnings, blessed by accountants, are not really being earned. When you reach for the money, it melts away. It was never there.

It [accounting for derivatives] is just disgusting. It is a sewer, and if I'm right, there will be hell to pay in due course. All of you will have to prepare to deal with a blowup of derivative books.

Likelihood of a Derivatives Blowup
We tried to sell Gen Re's derivatives operations and couldn't, so we started liquidating it. We had to take big markdowns. I would confidently predict that most of the derivatives books of [this country's] major banks cannot be liquidated for anything like what they're carried on the books at. When the denouement will happen and how severe it will be, I don't know. But I fear the consequences could be fearsome. I think there are major problems, worse than in the energy field, and look at the destruction there.

I'll be amazed if we don't have some kind of significant [derivatives-related] blowup in the next five to ten years.

I think we're he only big corporation in America to be running off its derivative book.

It's a crazy idea for people who are already rich -  like Berkshire - to be in this business. It's a crazy business for big banks to be in.

Yo would be disgusted if you had a fair mind and spent a month really delving into a big derivative operation. You would think it was Lewis Carroll. You would think it was the Mad Hatter's Tea Party. And the false precision of these people is just unbelievable. They make the worst economics professors look like gods. Moreover, there is depravity augmenting the folly. Read the book F.I.A.S.C.O., by law professor and former derivative trader Frank Partnoy, an insider account of the depravity of derivative trading at one of the biggest and best-regarded Wall Street firms. This book will turn your stomach.

Sounds like the beginning of a joke, right?  So these two guys walk into a bar…

“The” Bruce Schneier and Marcus Ranum have an article up on TechTarget/Information Security Magazine called, creatively enough, “Bruce Schenier, Marcus Ranum debate risk management“.

Unfortunately, to get to the article, you’ll have to either already be a subscriber to IT Security, a subscriber to TechTarget, or go through the 20 minute process of signing up by giving TechTarget all sorts of “market information” about how you’re really Brandon Walsh, CSO of “The Peach Pit” Industries in Beverly Hills, CA 90210 (phone 714-867-5309).

For those of you who are already a TechTarget person, the link is above.  For those who aren’t, or those who just don’t have the time, I’ll summarize.  The “debate” is kind of awkward because both authors seem come to the same conclusion:

Risk Management, it’s something our profession should do, something humans do naturally, it’s necessary in business, but gosh - we don’t have enough data.

I’m not a cryptographer.  I don’t *nearly* have the insight on privacy and politics that Bruce has.  I’m not deep in IP communications.  I haven’t got a proven track record of innovation in IP Security products like Marcus has.  But here’s the thing, I hope you’ll never hear me pretend that I have the skill set to speak authoritatively on those subjects.  Heck, I wouldn’t claim to be a “risk” expert because I have a some insight into my shortcomings and what is needed to tackle such a complex problem.  But such a tepid article on something that (at least I think) is so important kind of, well, confuses me.

Why is it such a boring article?  I’m not sure.  Maybe because they’re just two guys who would rather debate the merits of specific controls or control activities (after all, their penetration testing debate was a huge success), but there’s no new information in the “debate”.  It’s the same old “insurance companies know risk because they have scads of data and we don’t have that” complaint. You know what?  I’m tired of hearing that line, so let’s talk about it.

HOW DO YOU KNOW WE DON’T HAVE THE AMOUNT OF DATA WE NEED TO DO RISK MANAGEMENT WELL?

Not particularly picking on Marcus, but in the article he uses the common complaint, “We lack the data to do risk management well.”  This mantra is repeated to the point where I’m blase’ about it.  But for some reason, this sentence really jumped out at me this time for two reasons.  It made me ask:

1.)  How do you know we don’t have the proper amount of data?

2.)  Can we even define “well” (i.e. what “good” risk management is) yet?

I really don’t know that the industry, especially concerning IT risk, is mature enough to really conclude that we don’t know (in the case of the former), nor that we can define (latter), conclusively.

PLAYING THE CONTRARIAN

Just because I’m feeling kind of zany this morning, let me suggest something.  Maybe there actually is lots of evidence out there for us to use.  Maybe:

1.)  It’s just that we don’t have particularly good models that provide context.

2.)  When that evidence isn’t an obvious phenomena that lends itself to easy measurement, we throw our hands up in disgust and fall back on “lack of data”, “can’t quantify risk”, “best practices work just fine” or any other number of arguments, no, excuses we use to justify our inability to be precise about the past (more or less the present or future - apologies to Niels Bohr).

IT’S IN THE WAY THAT YOU USE IT

Now I actually am happy to acknowledge that we don’t have enough data to be precise.  You, me, even smart guys like Marcus and Bruce - we’ll never be able to “engineer” risk management.  But you know what?  Neither can Insurance companies.  Sure, there are plenty of places where they have enough data to apply a traditional frequentist approach to risk valuations.   But there are plenty of times Insurers actually insure and they don’t have centuries or decades of data.  There are plenty of times when they rely on the “estimates” of subject matter experts.  There are many times they have enough information to be accurate rather than precise, and that’s good enough for them.

For that matter, it’s worth noting that there are plenty of scientific disciplines that have to deal in imprecise prior information, or evidence that’s fraught with uncertainty (what Ranum calls “squishy”, and what I’ve heard real honest to goodness physicists call “noisy”).  Unfortunately, we’re going to be like them.  Until we can read minds and predict the future, there will always be uncertainty in our measurements and posterior conclusions.  The trick is in how you deal with it and express it.  And while I really don’t know how much time Marcus or Bruce have really spent in the deep end on the subject of risk and its management - I have seen people doing brilliant things around risk (though they just aren’t mainstream).  Whether the tools are Bayesian methods, Monte Carlo engines, reductionist models of complex problems, there are risk analysts trying to deal with the problem.  These analysts are applying scientific method(s) and developing reasonable approaches to a very complex problem.  There are people trying, and our body of knowledge is growing, growing well beyond “gee, I haven’t got an obvious solution so I’ll blame it on lack of data”.  Heck, I’ve seen readers of this blog suggest Douglas Hubbard’s book in other security forums!*

I’VE GOT YOUR DATA RIGHT HERE…

But we don’t have enough data?  I have to ask, how much more do we need?  I mean crikey, JPMC just visited our ISSA chapter claiming, like, a bajillion events an hour.  There’s not one, but several companies out there that will want to tell you about how they have deep “insight” into the attacker community.  The boundaries of IT Risk losses are pretty well established by events that happen to public companies.  We have pretty mature testing/assessment tools and methodologies now that help us test our ability to resist the force an attacker can apply to us.  So what part of the Threat Landscape, Asset (Controls) Landscape, or Loss Magnitude landscape is too incomplete (and what are you doing to find the information you need)?

SO WHY DO WE FAIL?

Which brings me to a final, somewhat depressing conclusion.  Maybe there’s data, and maybe we’re starting to see the means to use it.  But in the end I do have to agree with Marcus that the vast majority of the infosec world *is* doing a really, really bad job with regards to “risk” and “risk management”.  The majority of people I know consider GRC to be a cruel, expensive joke.  Risk Assessment Methodologies tend to be built on the faulty premise that if we create a repeatable process, our measurements and conclusions will magically become accurate and wise.  Risk models tend to be factors loosely measured by ordinal scales and then somehow “multiplied” together to create a relatively meaningless qualitative value.  The State of the Union here is not good.  But after reading such a superficial treatment of an important and complex subject, I am left wondering if Bruce and Marcus were the right people to write about risk management in a mainstream publication.  As Inspector Callahan says, “A man’s got to know his limitations.”

===============================

* Speaking of which, if you want to do one cost effective thing to address your uncertainty - go find Douglas Hubbard’s book. It’s even got a nice recommendation from Peter Tippett.  The book is called “How To Measure Anything” - the title sounds rather hyperbolic, but there are good techniques in it we can use to identify useful information and refine our ability to frame that qualitative information into quantitative values. The key is how Hubbard has you deal with your uncertainty.  For those of you who are more scientific minded and want to dig deep into the subject, I have on good authority that E.T. Jaynes “Probability Theory, The Logic of Science” is a rather under appreciated work.

So can open source weather out the economic storm? Emerging from the dot-com bust, open source has matured, its legal framework and values are established, and serious players are in the game. But as this post on ZDNet points out, consolidation is on the way. “IDC renamed its LinuxWorld Show in San Francisco next year Open Source World – a clear shot across the bow at O’Reilly’s OSCON.” Will open source (from free to lower-cost alternatives to commercial software) flourish in a time of tightening budgets or will projects quietly go away for lack of funding (VC and that pesky business model thing) and, let’s face it, the “extra time” of IT pros tasked yet again to do more with less?

It’s October 2008 and Charles Babcock writes, “CA Embraces Virtualization As Future of Data Center Management”. Beyond keeping up with what competitors are doing, I enjoy this article for the masterful way it depicts the nightmare that is working with traditional frameworks. Too slow, too expensive, too complex, too many modules – it’s all in here. And somehow, I don’t think that was the point of it. So, $154,000 for CA Data Center Automation Manager – which can “consult” the CA CMDB (pricing starting at what do you think, something like $500K to a million – don’t forget those services) plus CA Wily APM (Introscope 8 and Wily Customer Experience Manager 4.2; pricing anyone?) metrics that get fed back into Data Center Automation Manager to help determine the virtual machine resources that are needed. Plus can also integrate info from CA Endeavor’s software change management tracking and CA SysView and in future with CA Management Suite for Mainframe Linux, potentially. I am not kidding about this list. And, we’ve been hearing this for a while – “Unicenter” the brand goes away and is replaced by “CA NSM”. The brand goes away. Why retire a successful brand? Ah.

I love this post on EMC, “Eleven Things You Didn’t Know About the World’s Largest External Disk Storage Company.” Although I guess I really don’t know much about Joe Tucci, since #11 says:

“Contrary to conventional thought, it is not true that the EMC President/CEO is the older, gentler brother of the fictional patriarch of HBO’s hit television series.” Hunh. I just googled him, thinking maybe it was a resemblance thing. Nope."

And on a much lighter note. A funny from Dell. 2 years later, I just stumbled across this Proprietaryville , Jibjab-ish video, called Dell the Journey. Legacy systems being escorted onto the Retirement Home bus. Michael Dell as knight in shining armor, singing no less. Joe Tucci and Larry Ellison showing up as heroes leading the charge against Proprietaryville (yes, funny in and of itself). And my favorite, “Now let’s go kick some proprietary apps.”

The report was written by a committee whose members include William Perry, a professor at Stanford University; Charles Vest, the former president of MIT; W. Earl Boebert, a retired senior scientist at Sandia National Laboratories; Cynthia Dwork of Microsoft Research; R. Gil Kerlikowske, Seattle's police chief; and Daryl Pregibon, a research scientist at Google.

They admit that far more Americans live their lives online, using everything from VoIP phones to Facebook to RFID tags in automobiles, than a decade ago, and the databases created by those activities are tempting targets for federal agencies. And they draw a distinction between subject-based data mining (starting with one individual and looking for connections) compared with pattern-based data mining (looking for anomalous activities that could show illegal activities).

But the authors conclude the type of data mining that government bureaucrats would like to do--perhaps inspired by watching too many episodes of the Fox series 24--can't work. "If it were possible to automatically find the digital tracks of terrorists and automatically monitor only the communications of terrorists, public policy choices in this domain would be much simpler. But it is not possible to do so."

A summary of the recommendations:

• U.S. government agencies should be required to follow a systematic process to evaluate the effectiveness, lawfulness, and consistency with U.S. values of every information-based program, whether classified or unclassified, for detecting and countering terrorists before it can be deployed, and periodically thereafter.

• Periodically after a program has been operationally deployed, and in particular before a program enters a new phase in its life cycle, policy makers should (carefully review) the program before allowing it to continue operations or to proceed to the next phase.

• To protect the privacy of innocent people, the research and development of any information-based counterterrorism program should be conducted with synthetic population data... At all stages of a phased deployment, data about individuals should be rigorously subjected to the full safeguards of the framework.

• Any information-based counterterrorism program of the U.S. government should be subjected to robust, independent oversight of the operations of that program, a part of which would entail a practice of using the same data mining technologies to "mine the miners and track the trackers."

• Counterterrorism programs should provide meaningful redress to any individuals inappropriately harmed by their operation.

• The U.S. government should periodically review the nation's laws, policies, and procedures that protect individuals' private information for relevance and effectiveness in light of changing technologies and circumstances. In particular, Congress should re-examine existing law to consider how privacy should be protected in the context of information-based programs (e.g., data mining) for counterterrorism.

Here are more news articles on the report. I explained why data mining wouldn't find terrorists back in 2005.

COBIT rivals ITIL from The IT Skeptic

“Everyone is tiptoeing around the fact that COBIT offers a significant competitive body of knowledge (BOK) to ITIL. Sure ITIL goes into more depth in places, but to say COBIT sits over the top is to grossly understate the overlap. COBIT extends a long way down into the “how” and it does it with an intellectual rigour that ITIL lacks.”

Interesting stuff that.  A detailed mapping might help some folks.  Either way, the good news for those keen on understanding risk management is that governance metrics, done right, allow us to understand a part of that “capability to manage risk” we’re always looking for.   Assurance, verification and the acquisition and interpretation of knowledge is king.   Speaking of which….

How To Tell When “Nothing Happens” by Pete Lindstrom

“…problem is that, it isn’t really true that “nothing happens” when you employ some specific security control to prevent an exploit. Not only that, but even when it is difficult to collect data on what didn’t happen, one can devise experiments to tell how frequently that nothing occurred.”

Good analysis is all about the uncertainty.   Speaking of accounting for uncertainty…

Assets Good Until Reached For by Gunnar Peterson

“If you have a 100,000 dekstops or 100,000 servers it hard to manage. You will need to automate and to do that you need to abstract, but you should also realize that its a drawing on a whiteboard not reality. You need abstraction assurance.”

And there’s the trick.  We might call “abstraction assurance” an analog to “confidence” or “uncertainty” in certain priors (metrics) or posteriors (calculated values based on those metrics).  The stronger that abstraction assurance is, the less uncertainty we have in our knowledge and the better our ability to create wisdom from that knowledge (you know, make decisions).

Epstein, Snow and Flake: Three Views of Software Security by Adam Shostack

Adam’s focus is on software security, but the discussion here can be abstracted out into the broader realm of risk management quite nicely.

Two-thirds of firms hit by cybercrime from Security Focus

The US DoJ says that in 2005 (there’s some timely data) 2/3 of their surveyed firms detected at least one cybercrime.  “Cybercrime” is “classified … into cyber attacks, cyber theft, and other incidents.”  Pretty general.  Also from the report:  “Computer viruses made up more than half of all cyber attacks.”

(That sound you hear is me tapping my forehead lightly on large iron object)

Lessons Learned from “Personal” Risk Management By: Christopher Daugherty

“This process is what I call “personal risk management.”  All of us have done it and will continue to do so.  Why is it, then, many companies have ignored following similar principles with the on-going health of the business?  This is a debate with many different answers so I ask you to select the best answer for your employer:

a) Have not ignored as this keeps me awake at night!

b) Please restate the problem, I cannot hear well with my head buried in the sand.

c) We passed our SOX audit so we checked this off the list!

d) We are informed of the challenge but we have a business to run and profits to make

e) Is this what internal audit and risk management has been telling us?”