3 security acronyms to avoid (and 3 to embrace)

by Ken Stasiak, SecureState - If it were just that easy: The devil sitting on one shoulder and an angel perched on the other, each offering up his/her advice on security trends. Well, after you read this blog post, you will have all the information you require on the topic, and will not need any ethereal guidance. I’ve assembled two lists: one of security trends you’d do well to avoid, the other of security trends you’d be wise to embrace.

3 acronyms to avoid

1. GRC (Governance, Risk, and Compliance)

I’m not sure if three more unlikely words have ever been linked together before. Governance, Risk, and Compliance (GRC) is defined by Wikipedia as "an integrated, holistic approach to organization-wide governance, risk and compliance ensuring that an organization acts ethically correct and in accordance with its risk appetite, internal policies and external regulations through the alignment of strategy, processes, technology and people, thereby improving efficiency and effectiveness."

Seems pretty straightforward: Let’s go do this. But what is this? How do we implement GRC? Thus lies the problem with GRC. Being touted as the next big thing everyone is talking about and presenting on, new GRC products are being developed that will implement and track GRC, but I would caution you against throwing GRC into the budget. I suggest a more thorough examination of GRC and its implementation be done before organizations jump on the GRC bandwagon.

2. DLP (Data Leakage Protection)

If your organization is considering a Data Leakage Protection (DLP) solution, first ask yourself one question: “What type of data are we attempting to stop from leaking?” While this seems like a very simple question, the answer is quite complex. Many organizations are looking to implement DLP solutions without having a defined data classification guide. Without the basic principles of what is considered sensitive, DLP will be just another technology for technology’s sake. DLP should be implemented only if your organization intends to monitor its classification guide. [Remember IDS/IPS and the lack of a good Incident Response Plan (IRP), and how much trouble we had with that technology?]

3. CIA (Confidentiality, Integrity, and Availability)

As security professionals we still are concerning ourselves with availability. The CIA model was developed and used many moons ago, when a firewall constituted security, and the “A” actually made sense: you had to keep things running. We have evolved, and the issue of availability of resources should be moved to the realm of the CIO. Avoid taking on additional responsibilities that have no impact on security. Defining the responsibilities and roles of the security department/officer is critical. Yes, I did reverse the traditional order: Define your responsibilities first, and then determine the roles that are needed to implement those responsibilities. And remember: don’t take ownership of areas you cannot control.

3 acronyms to embrace

1. ISO 27001 (International Organization for Standardization)

Be careful with this one: I am not referring to ISO 27002, which is a list of controls. I am talking about specifically developing an Information Security Management System (ISMS) that allows an organization to spin the PDCA (Plan, Do, Check, Act) wheel, when changes to the environment occur. The days of a SAS 70 being sufficient are gone; financial institutions are requesting their service providers become ISO 27001 certified. Alignment with ISO 27001 can assist with organizations’ compliance with regulations and provide a framework that can take advantage of efficiency and effectiveness gained from organizational governance.

2. PII (Personally Identifiable Information)

Privacy has been and will continue to be a hot topic; however, if you are an international organization, you definitely should watch for it on your radar. While Information Security may consider privacy part of their jurisdiction, it should be the responsibility of Legal and HR. Information Security should be present to guide the protection of information, but should not own the compliance and/or business processes surrounding Personally Identifiable Information (PII). With the E.U. Safe Harbor framework, many organizations are scrambling to understand what this means, and whether other countries will accept the standard (i.e., Germany), or whether the standard will accept them (sorry, Mexico). One idea which often is overlooked when discussing PII is the presence of a good Incident Response Plan (IRP). Privacy regulations are very particular with regard to PII being leaked or breached. When performing a privacy assessment, be certain to allocate some of your budget to the development/update of your IRP.

3. ERM (Enterprise Risk Management)

I cringe when saying this, but organizations need to start consolidating all risks into one risk portfolio. Too often Security holds the technical risk for the organization, without pronouncing this outside the CIO. Technical risk should be one more input into a bigger, broader risk management approach, allowing the organization to understand all facets of risk, which would precipitate better decision-making and distribution of resources. You think the CFO has trouble obtaining budget? As we saw with the banking environment, Security could have identified a huge gaping hole from the outside that would allow full system compromise; however, we didn’t ask if the bank had enough funds to stay in business tomorrow. This is called operational risk, and it often trumps technical security risks. With Enterprise Risk Management (ERM) comes a comprehensive risk assessment equation and process. Defining one process that can be used and incorporated into the entire organization will allow for conformity, efficiency, and effective alignment between departments. I would refer you to ISO 31000:2009, which provides principles and generic guidelines on risk management.

Ken Stasiak is CEO and Founder of SecureState

Top 10 Hot Internet of Things Startups
Join the discussion
Be the first to comment on this article. Our Commenting Policies