Everyone wants information security to be easy. Wouldn’t it be nice if it were simple enough to fit snugly inside a fortune cookie? Well, although I don’t try to promote such foolish nonsense, I do on occasion pass on readily digestible nuggets to reinforce security principles and get people thinking how security applies to their environment.

Common Sense
I think the key to fortune cookie advice is ‘common sense’ in the context of security. It must be simple, succinct, and make sense to everyone, while conveying important security aspects.

Here is my Fortune Cookie advice for June:

A perfect security program does not make your environment invincible! It would be astronomically too expensive. The ‘perfect’ security program achieves the optimal balance of spending, loss prevented, and acceptable losses (residual loss).

Now if I can just figure out how to stuff these little cookies…

Am I contributing to the problem of over simplifying security? Or am I reaching out to those who might not take an inordinate amount of time necessary to understand the complexities and nuances of our industry? You decide and feel free to share your knowledge-nuggets.

Fortune Cookie Security Advice - May 2008

. via

It is vitally important to give data consumers an indicator of the quality of your information. This helps to build a trust in the completeness and review state related to what they are consuming. What we have implemented is real-time, includes embedded business rules and a pretty little display.

So what did we do?

• Created a Five tiered rating system Data Quality(DQ) State
• Moving through each tier means that data completeness and audited quality checks are performed
• As the software application moves through its life cycle, additional data elements become mandatory, which effects the dynamically calculated rating
• DQ State value exposed for interfaced consumption
• Shown on-screen with graphical representation

What is involved in each DQ State tier level?

• DQ State 0: does not meet minimum required data
• DQ State 1: Name, Business Description, Status, Manufacturer, Owner (Group/Contact)
• DQ State 2: State 1 plus - Host, Software Type, User (count/location), Data Classification, Technology categories
• DQ State 3: State 2 plus - Cost Assessment
• DQ State 4: State 3 plus - Capability categories, Network communication details, Business Continuity details

This tiered approach begins to define higher quality for the data completeness as it moves up the defined levels. Not only having the blanks filled in, but the application of embedded business rules-based analysis to validate content, drives the state calculation. These are updated based on any change to any of the evaluated content.

What do you do in your organization? How do you ensure that the data “freshness” is preserved?

Previous topics include Application inventory, what do you capture?, Application inventory starts with a definition, Application inventory as a cost savings initiative and Application Inventory, the start of data sustainability?.

. via

Since the previous post in October there has been much interest in our two pilots aiming to reduce information overload; and I’ve responded to all of them with the quintessential engineering attitude of “we’ll have to wait until the data is in”. Well, the data is finally in, and now I can reward your patience and share the main points.

You will recall we were running two pilots:

1. “Quiet Time” on Tuesday morning.

In this experiment 300 engineers and managers, located in two US sites (Austin, TX and Chandler, AZ), agreed to minimize interruptions and distractions every Tuesday morning. During these periods they had all set their email and IM clients to “offline”, forwarded their phones to voice mail, avoided setting up meetings, and isolated themselves from “visitors” by putting up a “Do not disturb” sign at their doorway. The purpose was to see the effect of 4 hours of contiguous “thinking time”.

On the whole, the 7-month pilot returned markedly positive results. It has been successful in improving employee effectiveness, efficiency and quality of life for numerous employees in diverse job roles. 45% of post-pilot survey respondents had found it effective as is, and 71% recommended we consider extending it to other groups, possibly after applying some modifications.

As expected, this is not a matter where “one size fits all”: not all people found this a desirable practice, depending also on their specific job roles. But an interesting finding is that Quiet Time is useful to different people for different reasons. Some people need it to concentrate on creative tasks, as we had predicted, but even people whose work involves ongoing interaction with others found the periodic “breathing space” beneficial in restoring balance and getting back in control of an otherwise hectic work routine. One should, we learned, let each person decide how to use the quiet hours to best effect. A key success factor, however, is that people must realize that the “quiet” requirement is not absolute; when an urgent situations requires it, interruptions are permitted. Communicating this clearly was necessary halfway through the pilot.

2. “No Email Day” on the Friday.

It has been noted (and often ignored) that “No Email Day”, or “Zero Email Friday”, is a misnomer; but it has caught widely before we got to it and we kept the name. In reality, email is not forbidden on the Friday; the idea is to solve the problem where people send email to a coworker in the next cubicle rather than walk across the aisle and talk, by encouraging the use of face to face and telephone conversation in preference to email within an organic group, which in our case comprised 150 engineers and managers.

This pilot has achieved lower success than “Quiet Time”, though 29% of respondents did find it effective, and 60% recommended we consider extending it to other groups. The issue, we found, is that there was a clear incompatibility of NED with the nature of work in the chosen pilot group, where many people are routinely away from their desks or in meetings much of the time. This renders asynchronous email the method of choice for connecting to people in the group. It is easy to conjecture that for NED to work better, it should be applied in teams that are not only collocated, but also tend to sit in their offices most of the day, so your coworker is predictably available to be spoken to synchronously when the need arises.

Our next steps will be to present these data to management and consider proliferation to other groups at Intel who might find either or both practices useful in the context of their work style.

. via

I have just returned from the Intel sponsored Eco-Technology Great Debates where I was slotted into the topic of Thin vs. Thick Client Energy Efficiency. I had the opportunity to weigh in on the side of “Thick” clients as the most energy efficient. The bad news is that our team lost; the good news is that we didn’t lose by much (29 to 24)! The best news is that all of the teams had some very strong arguments (and even several very entertaining exchanges).

Being a simple data center guy, I learned a lot, especially as it relates to thin client architecture and energy impacts. No contest, thin clients consume less energy at the device level than do thick clients (PCs and Laptops). But is that really the energy efficient answer?

For thin clients, compute and storage are necessarily displaced to the data center. Data centers with thier concentrated IT equipment are typically inefficient to power and cool relative to laptops and PCs which are distributed by nature and cooled by ambient air. Generally data centers require 1 watt of power for cooling and electrical distribution (house load) for 1 watt of IT load (newer data centers are more efficient but still incur additional power costs simply to power and cool). Therefore, every kW of power that is shifted from distributed thick client use to a data center causes more or less 2 kW of impact in the data center! Wow!

With the majority of the world’s data centers facing power or cooling capacity constraints and some with no additional grid power available at all, total energy costs extend beyond the simple house load + IT load equation. Expansion and upgrade of facilities increases energy consumption, as well. There are too many areas to detail here but needless to say the total power consumption for extracting and manufacturing data center components, transporting them to a site and construction of new facilities is non-trivial and likely larger per unit of compute than for the typical laptop. This collateral consumption is not comprehended in any calculations of alternative client model power efficiencies of which I am aware..

I also have no specific data on the power efficiency of PCs or laptops to provide rigorous comparison to data center power utilization efficiency. The above arguments, however, do appear to be logical. More work needs to be done to collect the data and analyze these concepts in detail…..

If you want to see the instant replay of all of the debates (including the client debate, liquid vs. air cooling and ac power vs dc power in the data center), click on the web link above and look for the embedded webcast URL at the bottom of the resulting page. There are also a couple of links to other articles on the subject that are well worth reading.

TTFN!

. via

It’s inevitable… a few times a week, my system slows to a crawl doing seemingly mundane tasks. Moving from one application to the next, or even navigating our intranet becomes a trial of patience. Originally I thought it was the application set I was using on a daily basis. Enterprise resource planning, internet browsers, development studios, mail and instant messenger clients. Each of these a known resource hog vying for what little available scraps of memory my system would cough up.

After some hallway grumbling with my co-workers, I turned my attention to not what I was running but what was being run for me. Automatic backup utilities, automatic patching software, and in the anti-virus suite with its omnipotent host intrusion protection. These applications lurk in the background, helping to keep us safe from the pitfalls of the electronic age. They are absolutely necessary to protect our company and its stockholders, but the value can come at a high cost.

Any one of these apps coupled with your normal application load can bring an older system to its knee’s on its own, but how about your backup utility kicking off while your antivirus software is in mid-scan as you happen to be running collaboration software sharing out a debug session in your development studio. Not pretty.

The productivity loss is cumulative… two minutes here, five minutes there, ten minutes for a reboot after a hard crash. Soon you’ve lost an hour or two over the course of the week, or a day or two over the course of a month. These things can be minimized by having systems capable of handling the multiple application loads that both the users need, and the ever shifting security environment requires. The threats won’t ever go away. More than likely, they will get worse and the applications needed to stop them will get bigger and more resource intensive.

. via