Posts Tagged ‘security automation’

Baby Steps – Information Security Process Improvement

Posted in Business and Security on November 13th, 2009 by Paul – 2 Comments

Organizations can quickly become overwhelmed when trying to implement a comprehensive information security program.  There are many barriers.  Cost.  Time.  Competency.   As I’ve posted before, security is an ongoing process and needs to be in order to deal with the changing business environment and evolving threat landscape.  Instead of implementing the very best (and most expensive) solutions for every security issue, I suggest a tiered approach that covers multiple areas and sets the stage for continuous improvement.

Barriers

Cost

If we buy the very top solutions for all of our security problems we will quickly run out of cash.  Throwing money at one or two issues leaves many other areas uncovered.   It may be better, especially early on in the implementation of an information security program, to spread the money around.  Provide coverage in all areas and then build up those controls that provide the most bang for the buck.

Time

The top solutions usually take more time to implement.  You need to ask yourself how great of an exposure do you have during the implementation?  Do you create a greater risk than by implementing a “lower end” solution?

Competency

I’ve seen it more than once.  An organization purchases and installs a high end and expensive solution that nobody on their staff knows how to use.  The great solution is subsequently ignored.   If nobody knows why a new process is being used or how a new product works, it’s pretty difficult to get the results you’re after.

Baby Steps

Continuous process improvement can apply to information security.  If you’re trying to implement a framework that calls for multiple controls such as ISO 27001/27002, using a multi-level approach may help reduce the paralysis that often accompanies such a large undertaking.   I suggest using a 3-tier approach.  Tier-1 is easiest to implement but is usually least effective.  Tier-3 is hardest but most effective.

tiered_security

It would be ideal if we could apply Tier-3 solutions to every problem right out of the chute but that simply isn’t feasible for most businesses.   Doing nothing is also a bad choice.  Applying Tier-1 and Tier-2 solutions at least gets the program moving and then process improvement can gradually improve the overall security posture of the business over time.

As an example, let’s look at dealing with security logs.

Tier-1

Administrators review server logs.  This is instituted through policy that requires the administrators to “regularly” review their logs.  We all know that manual review of logs is seldom done however, applying the policy at least sets the tone and expectation.  It can even start to adjust the administration culture toward reviewing logs if they don’t already do so.

Tier-2

Centralized log aggregation with automated reports.  This starts to automate the process.  Logs from systems and devices are pushed or pulled to a central logging system and now administrators review logs in this single location rather than across multiple servers.  Some scripting can be applied to automate reports.  This certainly increases the effectiveness of the log review process.

Tier-3

Commercial log analysis tool with near real-time alerts for anomalies.  This is a heavy-duty log aggregation, correlation, analysis, and reporting tool that has advanced capabilities.  It is much more expensive than a central log repository in Tier-2.  It is more complex to manage but the feature set allows for greater effectiveness.

Word of Warning

Implementing Tier-1 “just-for-now” solutions does not mean we can be lackadaisical in our information security practices.  Even basic security solutions need to incorporate good security principles.   If our business practices easily circumvent security controls then we can never be successful.   Starting small still has to be done right.

Surprising move by MasterCard

Posted in PCI on July 10th, 2009 by Paul – Be the first to comment

MasterCard made a decision not to allow remote key injection capabilities that allows merchants to install new encryption keys on point-of-sale devices.  Now these merchants are stuck doing this work manually at an off-site facility.  Organizations that are trying to comply with the Payment Card Industry – Data Security Standard are now hamstrung in their implementation capability, especially those who may have hundreds or even thousands of such devices.

It is unknown why MasterCard has taken this route but it certainly is a step backward in securing credit card information in transit and an increase in expense for merchants trying to comply.  This expense somehow will be passed along to consumers.

Considering the goal is to improve security by increasing the level of encryption, it is difficult to comprehend why automating this process would be a problem.  Considering a lot of money has gone into R&D for RKI research and it is designed to reduce the burden on merchants while improving security, I think MasterCard should have to publicly detail why they think that is bad.  There may very well be a reason behind this but as it sits, this is a defeat for secure credit card transactions.