In an age of intense global competitive pressure, more companies are striving to maintain an edge over rivals by continuous innovation and effective management of their technology base. This requires a manager who grasps both operations and technology, says Brad Fox, executive director of professional masters programmes at Duke’s Pratt School of Engineering.

“Companies . . . want people with technical depth, but [also] the business breadth that enables them to be successful at their jobs in a corporate environment. We’re really trying to prepare business-savvy engineers,” he says.

The US Navy has a goal to run 50% of its fleet on clean, renewable fuel sources.

The Navy is going green. Solazyme, the San Francisco-based renewable oil and green bioproducts company, recently delivered its 100 percent algae-based jet fuel to the U.S. Navy for testing and certification.

The fuel, showcased at last week’s Farnborough International Air Show in the U.K., is called Solajet HRJ-5, and it provides an 85 percent reduction in greenhouse gas emissions compared to traditional fossil fuels. It is designed to meet all of the requirements for Naval renewable aviation fuel. In early testing, it also met the fuel requirements of the Air Force and commercial aviation industry.

...

How did this arrangement with the Navy come about?

We went to the military to pitch this to them about two years ago, and they said to us, “It sounds great, but every biofuel company in America has come through here telling us the same story. So if you really want to do this, you have to make fuel and not just show us a PowerPoint.”

So at our own expense, we made a barrel of fuel and sent it to them. They said, “You’re the only company that has made us the fuel. Let’s do it.”

The intersection of business and technology is where the most interesting things happen, call it architecture, call it a MEM, call it a planner, but its about both having the business context *and* the ability to deliver. 

In my experience, Audit logs are one of the quick, dirty and cheap things that can improve enterprise security. Quick, dirty and cheap are a very rare trifecta in enterprise security and that by itself makes it worth paying attention to, but there are other good reasons for building visibility into your applications, that's neatly described by G.K. Chesterton (emphasis added):

The real trouble with this world of ours is not that it is an unreasonable world, nor even that it is a reasonable one. The commonest kind of trouble is that it is nearly reasonable, but not quite. Life is not an illogicality; yet it is a trap for logicians. It looks just a little more mathematical and regular than it is; its exactitude is obvious, but its inexactitude is hidden; its wildness lies in wait.

Access control models implement authentication and authorization models that rely on accurately identifying the subjects, objects, rules, conditions and actions that must be present to make an access control decision. This is sufficient to mitigate many threats, but does not account for all and specifically does little to address intentional misuse. This is where the accountability layer from such tools as audit log observers is essential. Monitoring has been confined to networks, which lack context that is available in the app and data layers, now we are entering an a moment where this is becoming apparent and starting to see the some large organizations putting monitoring at the app and data layers to understand the use and misuse of those resources.

There are several things an app can do more effectively than any other part of the stack. First you can add event-specific triggers to initiate some action, next the app has access to additional context that it can pull in as necessary, such as session data. Take an example like a web app that is reporting on vanilla HTTP information, a logger at the web server level just reports on request and response strings, however an app logger could have a trigger for a sensitive event (say, transferring money out of an account). In this case the logger can dump all session variables to the audit log including the authentication, access events, record management, transaction data, and other useful information.

So not only does the app have context that is not available elsewhere it can also be used to gather that additional context from sources.

In August 1992, when Hurricane Andrew was spinning toward south Florida, most experts in the “cat” risk assessment business were advising their insurance company clients to expect damages in the low hundreds of millions of dollars. Lloyd’s of London, more adventurous than most, suggested that the storm could cost insurers as much as $6 billion. Clark, whose five-year-old company was called Applied Insurance Research, thought they all had their heads in the sand. Her computer models, which had relatively little traction in the industry, put the potential damage at $13 billion — more if the overeager builders of south Florida had cut corners on local building codes.

An even greater problem, according to Clark, is that insurance companies are not collecting the right information. They’re stuck, she says, “in Fire World.”

“The insurance industry grew up in the middle of the last century, when the main risk was fire,” says Clark. “Today your house is still classified for its combustibility. The data collected on commercial properties are things like sprinkler systems and fire extinguishers. What’s wrong with that, from a business perspective, is that insurance companies now pay out about $9 billion to $10 billion in fire losses each year, but they are paying close to $30 billion for hurricanes, earthquakes, and winter storms. Companies are not collecting information that would indicate how susceptible buildings are to catastrophe. They need to start collecting things like roof type, roof age, and foundation type.”

Clark doesn’t expect a departure from Fire World anytime soon. “They’ve got hundreds of millions invested in systems, statistical plans, and collection processes,” she says. “They’ve got enormous IT systems all built around fire risk. It’s not the kind of thing that’s going to change overnight.”

And that’s a problem. Because in the wake of Katrina and other disasters, she says, it’s clear that a natural catastrophe could send us a bill in excess of $200 billion. The insurance industry will pay about half, and we — homeowners, business owners, and taxpayers — will have to pick up the rest of the tab.

“It’s not a question of if,” says Clark. “It’s a question of when.”

Today I did a keynote talk on Cloud Security: Yesterday, Today and Tomorrow. In the talk I described four essential architectural elements for Cloud security: Gateway (to limit attack surface), Monitor (Build Visibility In), STS (issue, validate, exchange security tokens), and PEP/PDP (dynamically make auth* decisions at runtime)

This is a great conference, not too big not too small. Filled with people with their hands on the wheel solving problems.

So it makes all the sense in the world to leverage it. I would say that it can be fed into a normal SOC and that creating a separate App Soc on its on island is not necessary in most cases.

The context comes from three things - 1) the location of the audit logger in the stack 2) the audit loggers' event model - what events is it aware of 3) the audit record format. Those three areas are the focus of building visibility into apps.

It begins:

Recently an acquaintance at the next table in a Palo Alto, California, restaurant introduced me to his companions: three young venture capitalists from China. They explained, with visible excitement, that they were touring promising companies in Silicon Valley. I’ve lived in the Valley a long time, and usually when I see how the region has become such a draw for global investments, I feel a little proud.

Not this time. I left the restaurant unsettled. Something didn’t add up. Bay Area unemployment is even higher than the 9.7 percent national average. Clearly, the great Silicon Valley innovation machine hasn’t been creating many jobs of late -- unless you are counting Asia, where American technology companies have been adding jobs like mad for years.

Consider this passage by Princeton University economist Alan S. Blinder: “The TV manufacturing industry really started here, and at one point employed many workers. But as TV sets became ‘just a commodity,’ their production moved offshore to locations with much lower wages. And nowadays the number of television sets manufactured in the U.S. is zero. A failure? No, a success.”

I disagree. Not only did we lose an untold number of jobs, we broke the chain of experience that is so important in technological evolution. As happened with batteries, abandoning today’s “commodity” manufacturing can lock you out of tomorrow’s emerging industry.

Hoff and I are leading a workshop at the Cloud Identity Summit on Security in the Cloud. The folks at Ping Identity put up a video with Hoff explaining the workshop. I am really looking forward to this, as Hoff says its a practical soup to nuts look at Cloud Security from infrastructure to metastructure (identity, policy, audit, BGP, DNS, SSL) to infostructure (apps and data).

Then I am speaking at Cloud Identity Summit on Cloud Identity: Yesterday, Today and Tomorrow.

 Steven Newman, the CEO of Transocean, said during a recent senate hearing, “There is some delay in the replication of our data, so our operational data, our sequence of events ends at 3 o’clock in the afternoon on the 20th. And so the VMS system, along with the logs of the VMS system, would have gone down with the vessel.”  The blowout and massive explosion happened at 10, taking eleven lives and seven hours of VMS data to the bottom of the ocean. Representative Bruce Braley from Iowa followed up with “So you have no mirrored backup data device so that that information is recorded at some other location than on the rig itself?”.  Newman replied, “We do not have real-time off-rig monitoring of what’s going on on the vessel”.

But as always, the tools only go so far and so its necessary to build the audit loggers into the code so that you can make the audit log manager useful. It would be nice if you had consistent event models, types and reporting as well. What we spend a lot of time on in training is - placement of the audit logger.

Location, Location, Location

Think about about a three tier architecture. Now think about an attack - let's SQL injection. What does SQL Injection look like at the presentation tier? Probably not much HTTP request, possibly with some funky characters, but its likely a "nothing to report" situation. (Yes I know I am glossing over the possibility of  the input validator catching it up stream, but bear with me) A little lower in the middle tier, mapping to business objects and applying business rules, it might trip a wire, but even there maybe not. Then at the data tier, formatting the query the logger may finally catch an exception or see something malformed and be able to 1) identify it as such and 2) report it. 

Then we do other exercises trying to audit log CSRF, XSS and other areas. In each case you will likely find that where in the code you choose to locate your audit logger is just as important as the events you are looking to gather.

Richard Bejtlich mentioned the topic of monitoring in a post, where he was posed a simple question (always the hardest kind) by a CISO Can you tell me when something bad happens to any of my 100 servers?"

Its worth reading Richard's whole post, but the part I want to include here is this part of his answer:

• Can we collect host and application logs?
• 
  
  • 
    
  • Do we have instrumentation in place to collect data for the servers in question?
  • 
    
  • Are the logs standard? Nonstandard? Obscure? Binary?
  • 
    
  • Are the logs complete? Useful?
  • 
    
  • What volume of data do we need to analyze?
  • 
    
  • What retention period do we have for this data?
  • 
    
  • What laws, regulations, or other restrictions affect collecting and analyzing this data?

Its a good list, and I would add a few more - 

• Where in the stack is the instrumentation?
• What is the event model? What event types are visible?
• How are the events, requesters and providers correlated?
• What event payload types are used?
• How are transactions and sessions handled?
• How are the identity information and authorities handled?
• What service interfaces, databases are monitored?
• Can you correlate identity providers, relying parties that vouch for transactions?

One of the smartest clients I have asked me to put together the Audit Logging training class (rule 1 in consulting - listen to your clients, especially the smart ones). He had been down the PCI road, had tooling and a basic event model, but needed concrete ideas, examples, patterns and practices on how hands on developers could integrate the audit logging beast into their apps. I put the class together and was leery that even though it seemed important topic, that anyone else would care, but it turned out to be a popular class.

One thing I have learned from reading Richard Bejtlich and studying real world security (ever lose a credit card?) responses, is that access control can only get you so far. When the stuff hits the fan its all about monitoring and response. Its hard to get the mindset to build security into systems up front and harder still to get people to think about building visibility in, but that's the best shot at mapping auditable events to the customers, users, identities, apps and data that you care about. To those about to audit log, we salute you.