It's basically what you would expect: Appoint a national cyber security advisor, invest in math and science education, establish standards for critical infrastructure, spend money on enforcement, establish national standards for securing personal data and data-breach disclosure, and work with industry and academia to develop a bunch of needed technologies.

I could comment on the plan, but with security the devil is always in the details -- and, of course, at this point there are few details. But since he brought up the topic -- McCain supposedly is "working on the issues" as well -- I have three pieces of policy advice for the next president, whoever he is. They're too detailed for campaign speeches or even position papers, but they're essential for improving information security in our society. Actually, they apply to national security in general. And they're things only government can do.

One, use your immense buying power to improve the security of commercial products and services. One property of technological products is that most of the cost is in the development of the product rather than the production. Think software: The first copy costs millions, but the second copy is free.

You have to secure your own government networks, military and civilian. You have to buy computers for all your government employees. Consolidate those contracts, and start putting explicit security requirements into the RFPs. You have the buying power to get your vendors to make serious security improvements in the products and services they sell to the government, and then we all benefit because they'll include those improvements in the same products and services they sell to the rest of us. We're all safer if information technology is more secure, even though the bad guys can use it, too.

Two, legislate results and not methodologies. There are a lot of areas in security where you need to pass laws, where the security externalities are such that the market fails to provide adequate security. For example, software companies who sell insecure products are exploiting an externality just as much as chemical plants that dump waste into the river. But a bad law is worse than no law. A law requiring companies to secure personal data is good; a law specifying what technologies they should use to do so is not. Mandating software liabilities for software failures is good, detailing how is not. Legislate for the results you want and implement the appropriate penalties; let the market figure out how -- that's what markets are good at.

Three, broadly invest in research. Basic research is risky; it doesn't always pay off. That's why companies have stopped funding it. Bell Labs is gone because nobody could afford it after the AT&T breakup, but the root cause was a desire for higher efficiency and short-term profitability -- not unreasonable in an unregulated business. Government research can be used to balance that by funding long-term research.

Spread those research dollars wide. Lately, most research money has been redirected through DARPA to near-term military-related projects; that's not good. Keep the earmark-happy Congress from dictating how the money is spent. Let the NSF, NIH and other funding agencies decide how to spend the money and don't try to micromanage. Give the national laboratories lots of freedom, too. Yes, some research will sound silly to a layman. But you can't predict what will be useful for what, and if funding is really peer-reviewed, the average results will be much better. Compared to corporate tax breaks and other subsidies, this is chump change.

If our research capability is to remain vibrant, we need more science and math students with decent elementary and high school preparation. The declining interest is partly from the perception that scientists don't get rich like lawyers and dentists and stockbrokers, but also because science isn't valued in a country full of creationists. One way the president can help is by trusting scientific advisers and not overruling them for political reasons.

Oh, and get rid of those post-9/11 restrictions on student visas that are causing (.pdf) so many top students to do their graduate work in Canada, Europe and Asia instead of in the United States. Those restrictions will hurt us immensely in the long run.

Those are the three big ones; the rest is in the details. And it's the details that matter. There are lots of serious issues that you're going to have to tackle: data privacy, data sharing, data mining, government eavesdropping, government databases, use of Social Security numbers as identifiers, and so on. It's not enough to get the broad policy goals right. You can have good intentions and enact a good law, and have the whole thing completely gutted by two sentences sneaked in during rulemaking by some lobbyist.

Security is both subtle and complex, and -- unfortunately -- it doesn't readily lend itself to normal legislative processes. You're used to finding consensus, but security by consensus rarely works. On the internet, security standards are much worse when they're developed by a consensus body, and much better when someone just does them. This doesn't always work -- a lot of crap security has come from companies that have "just done it" -- but nothing but mediocre standards come from consensus bodies. The point is that you won't get good security without pissing someone off: The information broker industry, the voting machine industry, the telcos. The normal legislative process makes it hard to get security right, which is why I don't have much optimism about what you can get done.

And if you're going to appoint a cyber security czar, you have to give him actual budgetary authority -- otherwise he won't be able to get anything done, either.

This essay originally appeared on Wired.com.

ScienceLogic: Mike, what’s your background working with network and management system tools?

Mike Lawson: Before joining Apptis, I worked for the Air Force, mainly in satellite communications for almost nine years. I’m probably most familiar with HP OpenView and BMC Remedy. I managed a team that used them but wasn’t involved in tool selection; like many other federal IT workers, we didn’t have a choice of tools because there were existing enterprise licenses and maintenance contracts.

I also saw a large systems integrator do a full Remedy/Crystal Systems/OpenView installation. It took 6 weeks to stand up and customize to meet just the basic monitoring requirements, and it cost something like half a million dollars. At the time, I thought that wasn’t bad and was a pretty typical experience.

ScienceLogic: Coming from where you did, what’s your take on EM7?

Mike Lawson: Honestly, I didn’t believe that EM7 could really do all that it claimed. In many ways, it was the complete opposite of what I had seen first-hand with other monitoring solutions. Could it really cover that much functionality? At relatively much lower cost to the customer and without the licensing nightmare?

That quickly changed when I needed to understand the system enough to run it at a customer’s site. I went back over the training docs I received during my initial training class and jumped in; now, 6 months later, I’m the EM7 expert and can tell you that it delivers on all those promises. (But I still need to show people to get them to believe it too)

I preach the “EM7 gospel” and when anyone wants to talk monitoring, I ask about the universal pain points: cost, maintenance contracts and licensing, and then I explain EM7. The cost difference is real; the solution is based on capacity, so there’s no licensing and it’s easy to use. They are shocked to learn that they can buy multiple EM7 appliances and years of maintenance for what they paid for most other tools.

ScienceLogic: Apptis won the contract for monitoring aboard the USNS Mercy. We love that you’re using EM7 for one of the Navy’s hospital ships. Can you tell us more?

Mike Lawson: The USNS Mercy is a Military Sealift Command hospital ship. Some stats:

• 849 feet long (nearly the size of a football field)
• 12 fully-equipped operating rooms, a 1,000 bed hospital facility, digital radiological services, a diagnostic and clinical laboratory, a pharmacy, an optometry lab, a CAT scan and two oxygen producing plants
• Crew: 61 civilian mariners, 956 Naval medical staff, and 259 Naval support staff

The USNS recently departed on a five-month humanitarian mission in the Western Pacific and Southeast Asia in support of Pacific Partnership 2008. The partnership provides international medical, dental and engineering teams this summer to provide humanitarian support and conduct joint, combined, and cooperative Civil-Military Operations in order to improve regional stability and build partner capacity to respond to natural disasters and pandemic.

For the most part, the ship’s network is self-contained, but can also use a landline when docked. The network covers 400 devices, including Windows/Exchange servers and VMware for server virtualization. Prior to using EM7, none of the monitoring was integrated; each system was independently monitored through individual vendor-specific consoles.

Out of the box, EM7 provided integrated systems, application and network management for all network gear, applications and virtual machines in one solution. We didn’t have to do a lot of customization – EM7 includes best-practice based thresholds, event and monitoring templates and this covered what USNS Mercy needed to monitor.

ScienceLogic: You’re a systems integrator with a very useful “customer point of view” when it comes to looking at tools. From that perspective, can you share what you think are the biggest benefits that EM7 provides?

Mike Lawson: First of all, EM7 stands up right away. We’re talking days, not weeks. In contrast to the lengthy installation of OpenView and Remedy I witnessed during my military career, I was able to configure, customize, and implement the EM7 solution for the USNS Mercy in three days.

Second, it’s easy to train people on and the support is outstanding. This judgment is from first-hand experience. Right before the USNS Mercy departed on its latest voyage, the system administrator I had trained on EM7 left, so I had all of a day to train some new EM7 admins. I prepared a seven-page “cheat sheet” and over a 3-hour conference call, we walked through the entire EM7 solution; I haven’t gotten a support call since.

And when a problem did crop up with a device being discovered incorrectly, ScienceLogic was very responsive. We contacted ScienceLogic support on a Saturday and they created and emailed us a video to help troubleshoot the same day. Within 30 seconds of watching the video, the problem was resolved.

Finally, EM7 helps us be good stewards of the government’s money. This is very important to me personally and to Apptis as a company. Because EM7 is cheaper and deploys so quickly and easily, you might think that it’s just the opposite of what a system integrator would want to use. But that’s short-term thinking. We believe in deliver the most value for customers every time. It’s what creates trust and long-term relationships with our customers. Instead of that half million spent on standing up the solution and basic setup, I’d much rather (and I know the customer would rather) spend that on fine-tuning or extending the solution to do much, much more.

As a former government employee, I know what it’s like to use a tool that doesn’t fit my needs. EM7 proves that the best solution can totally break the old model of costly, lengthy installations. EM7 has the right model: the right solution and the right price delivered as an appliance that is easy to deploy, train on and use.

ShareThis

It's basically what you would expect: Appoint a national cyber security advisor, invest in math and science education, establish standards for critical infrastructure, spend money on enforcement, establish national standards for securing personal data and data-breach disclosure, and work with industry and academia to develop a bunch of needed technologies.

I could comment on the plan, but with security the devil is always in the details -- and, of course, at this point there are few details. But since he brought up the topic -- McCain supposedly is "working on the issues" as well -- I have three pieces of policy advice for the next president, whoever he is. They're too detailed for campaign speeches or even position papers, but they're essential for improving information security in our society. Actually, they apply to national security in general. And they're things only government can do.

One, use your immense buying power to improve the security of commercial products and services. One property of technological products is that most of the cost is in the development of the product rather than the production. Think software: The first copy costs millions, but the second copy is free.

You have to secure your own government networks, military and civilian. You have to buy computers for all your government employees. Consolidate those contracts, and start putting explicit security requirements into the RFPs. You have the buying power to get your vendors to make serious security improvements in the products and services they sell to the government, and then we all benefit because they'll include those improvements in the same products and services they sell to the rest of us. We're all safer if information technology is more secure, even though the bad guys can use it, too.

Two, legislate results and not methodologies. There are a lot of areas in security where you need to pass laws, where the security externalities are such that the market fails to provide adequate security. For example, software companies who sell insecure products are exploiting an externality just as much as chemical plants that dump waste into the river. But a bad law is worse than no law. A law requiring companies to secure personal data is good; a law specifying what technologies they should use to do so is not. Mandating software liabilities for software failures is good, detailing how is not. Legislate for the results you want and implement the appropriate penalties; let the market figure out how -- that's what markets are good at.

Three, broadly invest in research. Basic research is risky; it doesn't always pay off. That's why companies have stopped funding it. Bell Labs is gone because nobody could afford it after the AT&T breakup, but the root cause was a desire for higher efficiency and short-term profitability -- not unreasonable in an unregulated business. Government research can be used to balance that by funding long-term research.

Spread those research dollars wide. Lately, most research money has been redirected through DARPA to near-term military-related projects; that's not good. Keep the earmark-happy Congress from dictating (.pdf) how the money is spent. Let the NSF, NIH and other funding agencies decide how to spend the money and don't try to micromanage. Give the national laboratories lots of freedom, too. Yes, some research will sound silly to a layman. But you can't predict what will be useful for what, and if funding is really peer-reviewed, the average results will be much better. Compared to corporate tax breaks and other subsidies, this is chump change.

If our research capability is to remain vibrant, we need more science and math students with decent elementary and high school preparation. The declining interest is partly from the perception that scientists don't get rich like lawyers and dentists and stockbrokers, but also because science isn't valued in a country full of creationists. One way the president can help is by trusting scientific advisers and not overruling them for political reasons.

Oh, and get rid of those post-9/11 restrictions on student visas that are causing (.pdf) so many top students to do their graduate work in Canada, Europe and Asia instead of in the United States. Those restrictions will hurt us (.pdf) immensely in the long run.

Those are the three big ones; the rest is in the details. And it's the details that matter. There are lots of serious issues that you're going to have to tackle: data privacy, data sharing, data mining, government eavesdropping, government databases, use of Social Security numbers as identifiers, and so on. It's not enough to get the broad policy goals right. You can have good intentions and enact a good law, and have the whole thing completely gutted by two sentences sneaked in during rulemaking by some lobbyist.

Security is both subtle and complex, and -- unfortunately -- it doesn't readily lend itself to normal legislative processes. You're used to finding consensus, but security by consensus rarely works. On the internet, security standards are much worse when they're developed by a consensus body, and much better when someone just does them. This doesn't always work -- a lot of crap security has come from companies that have "just done it" -- but nothing but mediocre standards come from consensus bodies. The point is that you won't get good security without pissing someone off: The information broker industry, the voting machine industry, the telcos. The normal legislative process makes it hard to get security right, which is why I don't have much optimism about what you can get done.

And if you're going to appoint a cyber security czar, you have to give him actual budgetary authority -- otherwise he won't be able to get anything done, either.

---

Bruce Schneier is chief security technology officer of BT, and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World.

Q1: How do you handle variety of log sources? There are so many, almost beyond my capability.

A1: Sorry to ponder the meaning of "is" here, but what is meant by "handle"? It is really not that hard to collect logs from a large number of diverse sources (as long as the logs can be delivered via syslog or exist as files and can be collected). Now, there will certainly be challenges  when the volume of logs gets large, but if by "handle" you mean "collect + store", it is really not that hard, given the right tools. Now, if "handle" means "make sense of what all those logs are trying to tell you," it is a different story altogether.

Q2: You talked about the importance of logging; however for an intermediate or novice admin what are the starting steps .. what are the minimal logs they should start at once?

A2: Answered in "Log Management - Day 1" If you want a simple list of things to "enable today,"  I cannot really answer it since I know neither your needs, nor your environment. In other words, this is the "what is the meaning of life question?" :-)

Q3: What regulations, rules or guidance exist regarding sharing or visibility of logs to users?

A3: PCI DSS says in Requirement 10.5:  "Secure audit trails so they cannot be altered.
10.5.1 Limit viewing of audit trails to those with a job-related need
10.5.2 Protect audit trail files from unauthorized modifications
10.5.3 Promptly back-up audit trail files to a centralized log server or media that is difficult to
alter"

NIST guidance for FISMA also says something similar (for example, look in NIST 800-92 doc). Overall, log protection and security are mentioned in many other regulations as well.

Q4: Privileged groups membership monitoring in AD one of the most important from my point of view. However I did not find effective way to monitor/report on changes in those groups. Any recommendations?

A4: This is indeed a tricky one which might take more space to answer than I have here; it might also take you 'beyond logs.' One good source of information is Randy Smith's site and, specifically, his webinar on 'Active Directory "Logging Gap"' (here somewhere) - which covers how to audit things of that sort when then native logging is not sufficient.

Q5: How I can learn what exactly I need to log?

A5: OMG, this is a $1,000,000 question :-) Let me answer "how can I learn" part and not the "what exactly I need to log part,"  (also see discussion on "MUST-DO Logging for PCI?") as it is actually answerable. To learn what you need to log, first ask "Why?" (and then see this) - basically establish what you want to accomplish with logs, catalogue your systems, figure how to tweak the logging knobs - and then do it!

Q6: How granular should logging be? What is your recommendation for enterprise servers like domain servers and Windows servers?

A6: Again, too long to answer here in details (it will become a subject of a longer blog post later), but some pointers follow: here for Windows (MS site also have a few recommendations on audit policies)

Q7: What is "more control" and what is "less control" that you mention in the webcast? Can you give an example?

A7: OK, I did say that "sometimes when you implement more controls, you actually have less control." What do I mean? If you buy a firewall (a network security control) and then - over time, of course - configure it with 7800 rules (!) that are supposed to give you control over who can and cannot access your network, you will not gain control over your environment. You will actually be less in control of who is touching your network, compared to, say, having only 20 rules.

Q8: What about mandated NIST controls for government systems? Auditing is a specific control for Moderate and High risk systems. What list of events do you recommend for auditing?

A8: This is too long to answer here, but NIST 800-92 Guide is a really good source of such info ("Guide to Computer Security Log Management [PDF]") Also, see my presentation on NIST 800-92 Guide in the Real World.

Q9: The issue that many organizations get stuck on, is the monitoring process, and defining what exceptions to monitor for? Is there guidance / framework for this? How much of it is system specific and how much is applicable generally to all systems?

A9: I outlined some general ideas back in 2004 via this presentation (note to self - update that to be more 2008-relevant); it is mostly general, but also has pointers to specific system. Keep in mind that it is focused on security, not operational monitoring (which is often no less important - in fact, often MORE important)

Enjoy! Sorry for being brief with some of the answers - I am woefully late with this even as they are...

Other questions that I answered in the past:

• More Log Management Questions - Answered!
• Some Burning Logging Questions - Answered!

What I found is that the two providers were using entirely different means to format the events! The email provider calls ToString(bool, bool) on the event to ask it to format itself. But the EventLogWebEventProvider does its own formatting of individual fields of the event. Indeed, its ProcessEvent method has a big list of checks:

if (eventRaised is WebBaseErrorEvent)
    AddErrorStuff();
if (eventRaised is WebAuthenticationSuccessAuditEvent)
    AddLogonStuff();

So it seemed like a better approach would be to write my own provider. I left the event log provider alone, and I wrote a custom email provider to display errors in a more useful way. This also allowed me to drop some fields from the event report that aren't useful for us. And I was able to construct a much more concise and useful subject line (the subject line that SimpleMailWebEventProvider uses is rather clunky since it assumes it might be spitting out a whole bunch of buffered events in one go).

Not only does my provider include the stack traces for all of the exceptions in the chain, but in the subject line, I display the type of error that is at the root of the problem. So if I am formatting a TargetInvocationException, I drill into its InnerException chain until I find a different exception type, and display that exception type instead.

Oh, one other benefit of building the custom provider instead of using a custom WebEvent was that I was then able to remove the Error handler from global.asax. All I had to do was replace the SimpleMailWebEventProvider with my own provider, and I got the behavior I wanted. Now my email notifications include detailed stack traces.

I'll post the code for this provider once it's run for a little while in production and I'm satisfied that it works reasonably well.

Braving the Cold (Boot) – A Sneak Peek of My Presentation at Black Hat

by Patrick McGregor

Cold boot attacks aren’t theoretical academic exercises. Cold boot attacks are real. And they’re serious.

In the past few years, companies have poured hundreds of millions of dollars into full disk encryption technologies. Companies expect full disk encryption to reduce the risk of exposure of sensitive information such as intellectual property or customer data. Reality often deviates from what is expected, however. Researchers from Princeton shocked the industry earlier in 2008 when they released a research paper that showed that low-cost “Cold Boot” attacks could be used to defeat the security of most full disk encryption systems. They recently even published all the tools needed to do this at home!

Some have argued that Cold Boot attacks are not serious security threats. I disagree! First, an unskilled person can capitalize on the exploit using simple, automated steps and publicly available tools. In fact, Cold Boot attacks require nothing more than plugging a USB drive into a laptop. Second, the physical target of a Cold Boot attack, such as a laptop, is very easily obtainable (see the recent Ponemon report on laptops lost/stolen in airports – scary!). Third, although many laptops and desktops are stolen via random acts of theft, it is well known that some criminals profit from organized, calculated data theft. It is only a matter of time before we hear of a high-profile data breach that results from a simple Cold Boot attack.

I am excited to present at Black Hat several innovations for preventing Cold Boot attacks. In addition to summarizing how a Cold Boot attack works, I’ll describe four new software techniques for hardening full disk encryption against the attacks. The software technology was developed by myself, Tim Hollebeek, Alexander Volynkin, and Matt White. All of us work for BitArmor, an exciting security startup based in Pittsburgh. Here’s a sneak peek:

· Wash up: Wipe keys immediately before certain OS state transitions, such as before the computer shuts down or goes into hibernation mode – accessing the memory will yield nothing.

· Take advantage of BIOS memory smashing: By strategically placing keys in certain regions of memory, we can rely on the BIOS boot process to overwrite keys before any operating system can dump the contents of memory.

· Is it chilly in here?: Using built-in temperature sensors, we can lock down the system in reaction to temperature drops that may indicate a Cold Boot attack is in progress.

· Create a virtual enclave for keys: We can implement special cryptographic, OS and processor architecture techniques to provide robust protection for keys against the most aggressive cold boot attacks. By creating a “virtual secure enclave” for encryption keys in software, an attacker cannot extract critical keys from memory – even if the RAM is super-cooled.

Hope you can join us at Black Hat as we take an in-depth look at the future of full disk encryption technology.