IT@Intel Blog

Fortune Cookie Security Advice - September 2008

Matthew Rosenquist — Wed, 17 Sep 2008 18:12:10 GMT

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 September:

In information security, like in sports, knowing your adversary is far more important than knowing the condition of the field.

Information security is an adversarial pursuit. It all begins with threat agents, those people who will negatively affect your organization. Some are malicious, others are not. The key is they are living, breathing opponents whose motivations drive actions which cause loss. They learn, adapt, and change as they seek their objectives.

Know your threats. This is an important first step. Knowing all your vulnerabilities is fine, but secondary in importance.

For those who are malicious, understand what they target and the likely methods they will employ. Only then can the vulnerabilities be narrowed to show the most probable exposures. This prediction gives the security professional a focus on what to protect, how best to monitor, and preparations necessary to respond when needed.

So 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 - August 2008

Fortune Cookie Security Advice - June 2008

Fortune Cookie Security Advice - May 2008

Deconstructing Cyber Security Attacks - Threat Model

Defense in Depth Information Security Strategy

Fortune Cookie Security Advice - August 2008

Matthew Rosenquist — Mon, 25 Aug 2008 17:27:54 GMT

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 August:

Security policy is like a seatbelt. It will not protect you every time, but it is guaranteed to fail if you choose not to use it.

No security policy is perfect. In fact, it should be a continuously evolving body of work which is improved as the industry changes and learns. The biggest challenge is not the exactness of the policies; rather it is the awareness and consistent adoption by the employees. An appropriate level of effort must be directed at the successful marketing and support by the target audience.

It may not be sexy, but policy can empower the Management support and maintenance of policy are key factors in leveraging this tool. Clear and straightforward verbiage coupled with sufficient marketing saturation can deliver necessary awareness to affect behaviors. With employee support of security principles, an organization takes a great step forward in achieving an optimal security posture.

A Company’s Greatest Security Threat and Asset

Fortune Cookie Security Advice - June 2008

Fortune Cookie Security Advice - May 2008

Are Security ROI Figures Meaningless?

Matthew Rosenquist — Mon, 25 Aug 2008 14:56:19 GMT

Recently, security expert Bruce Schneier expounded security ROI figures were meaningless! Is it true? Well, yes and no.

The brutal truth.
Well respected information security expert Bruce Schneier recently provided a stark opinion regarding the value of ROI's.
Follow this link to see the story:
http://www.zdnetasia.com/news/security/0,39044215,62037905,00.htm

In brief, Bruce stated security because numbers can be manipulated to justify anything.

He explained that the amount spent on a product can change significantly by simply playing with the equation.
"If the chance of you being attacked is one in a million and I change it to one in two million... I have halved the amount of money you should spend.
"I can make an ROI model say whatever I want. I could justify or not justify anything based on these very, very rare and very, very damaging events," he said.

Tell me it is not true!
I believe Bruce is both right and is delivering a message which is a little incomplete. His general message is accurate and shocking enough to garner the right level of attention. Most of the information security ROI's I have read were speculative, could not be validated, were impossible to reproduce, and had great latitude to provide results which benefit the desires of the author. Nowadays audiences are being provided ‘information' under the auspices of ‘fact', when in reality they are more of an opinion. Such valuation assessments are based on qualitative data versus quantitative metrics.

I blogged about the The Problem of Measuring Information Security back in August 2007

Awareness must be raised. I applaud Bruce in helping to make this happen. His message, as brutal as it sounds, is bringing to light a shadowy area in our industry. I think the follow-up message for audiences is to scrutinize and apply common sense to any ROI they come across. Understand the methodology and if it makes sense in their context. Lifting the curtain can quickly reveal a puppet master pulling the strings to artificially show value.

Like Bruce, I too have a jaded perspective. I have seen some WILD ROI's. Much of what I have read from security vendors is pure folly. However, just because most are fiction, it does not mean all methodologies are without merit.

Intel published a Whitepaper - Measuring the Return on IT Security Investments which is applicable to some situations. This method, far from being a silver-bullet, is a good start and has proven its truthfulness.

For any method, the accuracy should be scrutinized. Can it be validated, repeated? Was the method exclusively developed solely for self serving purposes from someone trying to sell something shiny? Does it make sense? These are the questions I ask myself.

On the bright side, many bright sharp people are working very hard to make the industry better and develop more rigid processes to insure both accuracy and confidence.

In the end, there is much work to be done in the information security valuation space. In the meanwhile, savvy consumers should be aware of the challenges and dive deeper into prospective ROI's and determine if they are ‘meaningless'.

Are today’s IT shops doomed to repeat the never ending cycle of re-inventing the wheel?

VirtualDave — Thu, 21 Aug 2008 18:32:55 GMT

As I sit back and think of some of the newer technologies we have looked at recently, I find myself wondering if IT is in the never ending cycle of re-inventing the wheel. What I mean by this is sometimes it seems as if we continue to try and re-engineer everything to make it fit our environment or how we think it should work. When viewing newer technologies, usage models and trying to pass data off to other groups the phrases I think I hear the most are, “That will never work in our environment,” or “If we can get them to change this, this and this, we may be able to use it here” or my favorite, “This will never be secure enough for us to use it as it exists”. While these may be valid assessments against the way we do things today, the big question is: should we be pushing ourselves to look for new ways of doing things? Five years ago, employees preferred to use their machines and software loads supplied by IT because they were more powerful or feature rich than anything they had at home. But in today’s society, people have higher end machines at home than IT supplies them. They also use newer technologies that are usually off limits or not supported by IT. Think of some of the tools we use today, such as this blog or even instant messaging. These technologies exist in our corporate environment because we saw people using them at home and brought them into our corporate environment. It wasn’t something that IT created and people took home to use. So with so many of these newer technologies out there, should we keep pushing to make them adapt to our IT world, or should we start pushing IT to start adapting to new models. We take umbrella approaches to everything today. Total security of the platform, instead of trying to reduce the footprint we have to manage. We look for solutions that will cover the majority of the users, versus what may be right for smaller enclaves. We place several management clients on the platform to perform numerous tasks instead of using native components or reducing some of the redundant requirements we have. Moving forward, the next generation of workers will expect businesses to offer familiar technology and won’t accept tradition as an excuse. IT shops need to provide workers with “cool” ways to work. If they don’t, they risk becoming obsolete.

A Company’s Greatest Security Threat and Asset

Matthew Rosenquist — Wed, 20 Aug 2008 18:03:49 GMT

Can an organizations greatest security asset also be its most serious threat? Yes it can.

The Greatest Asset
I manage information security for Intel’s mergers and acquisitions. Recently, I was evaluating an acquired company and delivering information security training to our newest employees on their collective hire date. As I was presenting the fundamentals of how to keep the company, their work, and our industry safe from cyber threats, an important security maxim was exemplified.

In interacting with the audience, I understood how they were accustomed to conduct business, the scope of information they handle on a daily basis, and their views on the value of security. I began to emphasize how the employee base was the greatest asset to information security and the combined force of a well informed, properly trained, and security savvy workforce dwarfs the efforts of the dedicated security staff. My recruitment speech sunk in and their faces glowed with pride. I saw a bit of excitement from the audience, that of empowerment and newfound responsibility. I was setting them up. Although absolutely true, a few slides later in my presentation I unveiled the stark reality.

The Greatest Threat
I asked to my newly recruited security champions what the greatest threat to the company was. Amid different answers, I revealed that THEY were the greatest threat. Not just them, but the entire workforce. The glow in their faces dimmed a bit. How can this be? How can our employees be both the greatest asset and the worst enemy in the cyber warfare trenches? They were shocked. They were dumbfounded. They were intrigued. I gave a dramatic pause. It is not often people are captivated by the boring and bothersome topic of information security. I savored the moment.

The real battlefield is in hearts and minds of employees. These new employees, more than any, represent the greatest challenge. They are accustomed to their previous ways, inundated with new-hire information, and are not familiar with the security expectations of their new corporate parent. Security policy is a distant concern on their first day. Every subsequent day, the separated cluster of workers will not benefit from the social reinforcement of good security practices as they are distanced from the collective body of experienced employees who exhibit secure behaviors.

We discussed how apathy, laziness, and circumventing policy for a quick gain, can cause significant weaknesses in security. Every employee has a responsibility to be secure and reinforce those fundamentals with their peers. A single employee through malice or carelessness can cause more damage than a legion of hackers. They must decide, through their actions, if they are the security marshals or the villains of the story. The battle is with the mindset of the employees. The finest security policy is worthless in the hands of an apathetic workforce.

In the end, the discussion was a success. It was not just training; it was an interactive dialogue talking to what is important and how every employee, now including them, work as a team to be Intel’s greatest security asset.

So, who do you market to?

Fortune Cookie Security Advice - June 2008

Matthew Rosenquist — Mon, 30 Jun 2008 15:33:44 GMT

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

How do you measure data quality in your Application Inventory?

John Simpson — Fri, 20 Jun 2008 18:28:22 GMT

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?.

BlogTalk Radio Discussion - Return on Security Investment – Intel Case Study

Matthew Rosenquist — Tue, 03 Jun 2008 16:26:16 GMT

Measuring the value of information security programs is difficult and a problem for the entire industry. In the second of the three part series, Intel discusses a practical approach to determine value of information security initiatives. Intel security professionals Tim Casey, Enrique Herrera, and Matthew Rosenquist discussed the success of Intel’s security value methodology outlined in the Whitepaper - Measuring the Return on IT Security Investments

Listen to how Intel utilizes this strategy as one means to measure the value of security programs. The whitepaper is available for download.

The 30 minute discussion can be replayed here:

The last of the three part series, Future State of Security Measurement, will occur on Wednsday June 4th. Everyone is welcome to participate or just listen in. Details can be found here:
http://communities.intel.com/openport/blogs/it/2008/05/12/how-do-you-measure-something-that-doesnt-happen

Fortune Cookie Security Advice - May 2008

Matthew Rosenquist — Tue, 27 May 2008 19:17:37 GMT

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 May:

Two types of victims exist...
Those with something of value, and those who are easy targets.
Therefore: Don't be an easy target, and protect your valuables.

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

BlogTalk Radio Discussion - The Problem of Measuring Security

Matthew Rosenquist — Thu, 22 May 2008 21:28:29 GMT

Good security conversations benefit all involved. The more we share, discuss, and challenge each other, the more we advance our industry. Thankfully, I have the benefit of working closely with a brigade of information security professionals and we banter at every opportunity, for the sheer pleasure and insights. In that same spirit, we hosted our first Blog-Talk radio session. This was a general discussion of the problems of measuring security.

The 30 minute discussion can be replayed here
Two other internet chats are planned. Everyone is welcome to participate or just listen in. Details can be found here.

Application Inventory, the start of data sustainability?

John Simpson — Wed, 19 Mar 2008 15:17:40 GMT

Up to this point I have covered Application inventory as a cost savings initiative followed by a discussion of Application inventory starts with a definition, and finally Application inventory, what do you capture?

Following the natural progression of:

Why inventory
Boundaries of what to capture
What to capture
How to capture

The "How to capture" is not a simple task completed in a week or two. For a company our size this task is still ongoing after fourteen months. And our progress shows us that we will need at least till the end of year to approach some semblance of sustainability. By sustainability I mean that the information, process and people will be in place to keep the data in a fresh state so that true data-based decisions can be made at near real-time.

Every day the clarity of our inventory gets sharper and sharper as we identify and pull in the data owners. The quality of the information becomes more focused as more of the profile is filled out. There are internal systems that are starting to rely on the data we have captured. That data is being transformed into true business information which has value and can be used to make the right decisions at the right time. At times, it still feels like an uphill battle. Each day we stand side-by-side with those who see the value and push on the back of our partners as we slowly progress up the hill.

Now knowing the definition and what data we want to capture we could have progressed in a multitude of ways:

Distributed work-load, individual owners
Focused work-load, our team owning (interviewing)
Centralized gathering (combination of above, driving people to a single location)

We chose to adopt the creation of a simple to use, centrally located (Intranet Application), that stored the data we needed. As mentioned in the past, we did our analysis by looking at applications on our enterprise that already contained the types of data we were interested in. What we discovered was that none of them had the flexibility to store the additional information nor the development resources to alter their systems. This pushed us to obtain permission to build a new application.

At this point you may be saying, "You built an application to reduce the number of applications?" Sometimes it is necessary to do the wrong thing in order to do the right thing. It would have been too easy to drop a spreadsheet out there and start gathering information. Short-term this would have cost the least and potentially would have allowed us to get part of the way there. The issue is the long-term sustainability and trust that comes from a solution like that. We would have security concerns, updating collision as well as the reduced ability to share the data easily with other applications.

Yes, we built a new application, using two people, in four weeks. Since implementation started we have supported weekly releases while expanding the data being captured, the usability for customers (and consumers) as well as enabling the removal of the majority of those other systems with parallel capabilities. We have great internal hosting solutions and have been operating non-stop since December 2006.

Our goal is still to do the right thing and properly manage our inventory through reduction. We were instrumental in providing the information and process needed to remove over 500 applications (and associated hardware) from our environment since we started our process.

In my next entry I will talk about some future enhancements to get us through the next year and the further reduction in application inventory we are charged with. Perhaps its time to start looking at how our original analysis for "Low Hanging Fruit" was successful and now we find ourselves making hard decisions in order to continue refining our inventory.

Have you had similar issues at your company? Do you currently have this challenge before you? I'm curious to hear some of those challenges and potential solutions.

Application inventory, what do you capture?

John Simpson — Thu, 21 Feb 2008 22:28:19 GMT

Up to this point I have covered Application inventory as a cost savings initiative followed by a discussion of Application inventory starts with a definition.

In our specific implementation, we started with a base set of attributes. Some of those were very obvious while others were necessary for managing some of our base enterprise capabilities. Items that were only captured in a 1:1 (one-to-one) relationship to any single specific application were:

Name
Description
Importance (a tiered level detailing the impact to our company)
Status (or state of the implementation)
Type (of application)
Manufacturer (if purchased)
Version
Owning Group
User Count

We also had some 1:M (one-to-many) related attributes which we cataloged in order to further build out the metadata for each instance.

Contact
Cost (develop, host, support, license)
Link (to external data)
Support
Technology

This was sufficient information for us to move along and begin consolidating data. As we engaged more and more teams and discovered localized stores of this data, our metamodel expanded to include a few more elements. Some of these also included associated increase in our own inventory tool capability. As this capability was implemented we were able to start turning off applications through consolidation (one of our key goals).

Additional Items (one-to-one)

Product Line (for ease of grouping and management)
Hosting Platform
User Description
Cross-Site Consumption
Customer Located External (to Intel)
Data Classifications (for information security and control)
Disaster Recovery Details
End of Life Tracking (legal and recovery data)

Additional Items (one-to-many)

Alias (alternate naming; the key to our success)
Capability
Component/Module
Customer Country/Region
Interface (consumption and providing)
Network Ports/Protocol
Product Testing (results, for future enterprise releases)

Many of them are specific to how we do business inside our company, however, you might find value in some of our learning's.

As I mentioned we discovered pockets of data and some little (and big) applications utilizing some of this data. It has become increasingly easy to implement an additional module that relates and consumes the data from the larger metamodel. From an architecture stand-point, we need to be careful not to develop this into a "jack-of-all-trades" application that does everything for everyone.

Up to this point we still only capture data (and functionality) that is related to the Application through direct relationship. As an example, we associate the application to what network port/protocol it uses, but not necessarily the network that is can pass across. We will capture the hosting platform name but not the specifics of that host. Instead we rely on interrelated systems to draw the larger picture of the whole enterprise.

Are we done?
Not even close. As noted in our Intel Information Technology 2007 Performance Report (page 12), this application and the associated capabilities we are developing is having a big impact. During 2007 we were instrumental in the end-of-life of over 450 applications. The metadata we capture and maintain have helped to identity instances of duplicity as well as opportunities where support and consumption have dropped to the point we can turn off the application.

In my next entry I will talk about how we were able to use two people resources and build an application in four weeks to solve this problem. Also how that solution has been running non-stop, for fifteen months with no downtime or impact to customers while increasing capability and usability while doing releases on average of every two weeks. Future posts will talk about some future enhancements to get us through the next year and the further reduction in application inventory we are charged with.

Have you had similar issues at your company? Do you currently have this challenge before you? I'm curious to hear some of those challenges and potential solutions.

Application inventory starts with a definition

John Simpson — Wed, 13 Feb 2008 21:19:07 GMT

Every software project I have worked on always started with some form of conflict and complicated interactions. This usually resolved itself through the use of a definition regarding roles and responsibilities. That definition kept people on the same page and helped everyone to understand who was doing what.

Now depending on when you happened to look at my job title over the last 13 years, you may have seen one of the following:

Software Engineer
Application Developer
Enterprise Application Developer
Software Developer

This means only that I moved from one department to another, however, the physical tasks I employed were the same. My output may have had a different installer/wrapper/output, however, it was the same. I designed, developed, tested and deployed an application into our environment.

When it was time to define the characteristic (metadata) of an application, we needed to start with definitions. Not only what an "Application" is but what "Software" is and how (if) it differs from each other and from an "Operating System".

This is vitally important because no matter who you talk to, they will have a difference of opinion in this area. Let me give you an example that we are currently dealing with. We are implementing a CMDB (Change Management Database) for our Service and Support organization. As our application data is pumped into that solution we had to decide whether it is an application or software. The CMDB definitions basically stated that software was the core items used to build a hosting platform whereas an application is the code hosted on that platform. A very specific definition for their very specific implementation.

Our definition was much more simple.

If it's coded, if you develop it, it is a software application simply referred to as an "Application". This can be developed internally or purchased. An application is not an operating system.

That means that everything running on our environment, that is loaded on top of an operating system, is an application and needs to be inventories. That also means if it is a web-based solution, with software code, hosted within a web-hosting solution, however, it is still an application.

We did draw a very discreet line in that we did not want to inventory certain things. Those are items that are "configured" inside of other applications. Item such as:

Web sites without dynamic content, hosted within a dynamic web solution such as Microsoft Sharepoint or created with Microsoft Frontpage or another WYSIWYG client.
Templates configured for an application.
Fileshare
Hosting Platforms (configuration of hardware and application software)

To put forth some simple rules, that people can evaluate their "Application" before attempting to add it for evaluation, we came up wtih some simple rules. It has to meet all of these with a yes response.

Installed on Intel (or contracted) hardware?
Initially used by more than one person (or application) at Intel?
Does this have (or has it ever had) a development/support team?
Does this have (or has it ever had) a development/release process?

This minimizes the possibility that we inventory applications that are sitting in a box, not installed on the environment. It also means that items we paid for, installed, licensed and such, are included. Whether on a server or on a client, we need to know about them so that we can work towards the simplification of our inventory.

Next I will cover how we have gone about gathering this data. Some approaches work well while others don't. Additionally, before you start gathering data you must have a solid review, maintenance and data quality processes in place or the data will be of no use for future analysis.

Have you undergone a similiar process? Are you struggling with doing this inside your company? Have questions? Let us know.

Application inventory as a cost savings initiative

John Simpson — Mon, 04 Feb 2008 18:30:33 GMT

Fourteen months ago my (new) manager approached me with a unique problem. It was discovered that we did a very poor job of keeping track of the applications (software) that we build and/or install within our enterprise environment. This lack of tracking also included all the associated data related to hosting (hardware, configuration and such). That's not to say that some organizations inside our company weren't doing a great job, however, these pockets of excellence were the exception not the norm.

My (now) manager explained that a new group will be forming to help find opportunities to save money in the application and hardware space. His problem for me to solve was that there was no single solution, no one source for data, nor any single location for recording information. As a technical lead with several years of experience in metadata modeling and tracking, he asked me to go off and propose a solution.

As I mentioned we had several pockets inside the company that were tracking data as necessary to perform their job functions. After performing an internal environment scan, analysis and in several cases, engaging with the teams and their tools, I was left holding an empty bag.

What did I discover? There were 12 different applications (out of vendorprovided and internally custom built) and around 14 additional data sources(spreadsheets and databases). Through engagement, it was determined that of the solutions, many were on aged technology and some had lost their developers to other projects. Additionally, most of the existing inventories had only one small piece of the puzzle. They were only concerned with that one bit of information that solved their business need. This meant that enhancing an existing solution was not going to work.

So off to the drawing board I went to try and come up with a quick solution that would enable us to rapidly gather our application inventory, the right way, the first time. My proposal was taken to senior management and four weeks later, three of us had completed the first version of an application which is still in use and the Record of Origin (ROO) for application metadata within our company.

How does this all save us money?
Let me give you an example that anyone can relate to. Think of this in terms of an inventory of the food in your cupboards. If you go to the store without any knowledge of what food (canned, packaged, frozen or fresh) you have, how do you know what to buy? One of the kids may know you have some corn, another may know you have a pot roast, however, is the inventory accurate? Until you get into all your cabinets and do an inventory, you'll never know what you have. Additionally, without putting a system in place to maintain that inventory, the next time you make dinner, your list is completely useless.

Continuing my food sample, let's say you want to make a lasagna. How do you know if you have the ingredients? How do you know you don't have one already, frozen and ready to heat?

This is the problem we found ourselves in (applications not food). We had no idea if we had overlapping functionality. Our capabilities were meeting our (internal) customer demands, however, were we meeting that need at a higher cost than necessary? Were we asking people to use a tool that was outdated (technically speaking) when a newer, faster, cheaper solution existed in the room next door?

These are some of the problems that we looked to solve. And with this, we have some pretty interesting plans on how to save money. I will cover that in my next entry.

Have you had similar issues at your company? Do you currently have this challenge before you? I'm curious to hear some of those challenges and potential solutions.

New Year’s Information Security Resolutions 2008

Matthew Rosenquist — Tue, 01 Jan 2008 00:23:00 GMT

With the old year grinding to a close and opportunities of a new year opening before us, it is a good time to take a moment and make some new year's information security resolutions. Some are good holdovers from last year and a few are new to the list. I think all are good practices to promote security and hopefully will keep a smile on my face throughout the year (no matter what cyber meltdown may occur).

Vigilance. Maintaining effective legacy security programs is critical. Loss of such capabilities opens the door to old, known, and well refined attacks
Embrace/Beware of disruptive technology. Double edged bleeding technology can be a blessing and a curse. It can reduce costs, increase efficiency, open markets, and change your way of thinking, but is also like walking into a darkened room in a horror movie. You never know what may jump out at you and in hindsight you may think "well that was painful". On the hot-list:
- Virtualization technology in all its glory
- Smart-phones and other PC OS/application based portable devices
- Social media sites, tools, and accompanying behaviors
Careful with my PII. Our Personally Identifiable Information (PII) is more important than anyone can measure. I will handle mine with care, insure others do the same, and simply say ‘no' more often than not, when asked.
Don't be a fish. Just say no to phishing and spam. Filters are wonderful but a few will creep through. If it looks suspicious, it probably is. Don't be shy, even with the weird stuff sent by people you trust. Just pick up the phone and call them: "Hey Ralph, did you send me this executable attachment via email?" Is it not that tough.
Give an effort for disaster preparedness. Regular backups and encryption are my friends. Nothing huge mind you, but at least apply where it makes sense
Choose not to be a victim and let common sense prevail. Two types of victims exist: those with something of value, and those who are easy targets. Therefore, don't be an easy target and protect your valuables
Talk and share security. We are stronger as a team striving for security, than alone. The bad guys are working together; it is about time we do the same. Talk about security and share what works or doesn't. Don't be shy.

Not rocket science, but most of the great ideas rarely are. Feel free to chime in and be heard. What are your security resolutions for 2008?