Pages

Wednesday, June 25, 2014

Focus on Fundamentals

Ok.  Let's face it.  The fundamentals are hard.  They're also boring.

They're also fundamental; they're the foundation.  Nothing can survive (long) without a foundation, and success will ultimately be limited by the limitations of the foundation on which that success is built.


In bicycling, our foundation is called the "base".  Base is earned through long miles in the saddle riding at a consistent and moderate pace, repeated over and over.  The typical training plan has 2-3 months of this stuff, mile after mind-numbing mile, as much as 3-4 days a week, with length based on how long races will be later in the year.  60 mile races?  4+ hours on the bike getting in base.


So, yeah, it's hard, and it's boring.


Bicycling, and Information Security, are both like building a pyramid.  If you want to go faster, ride longer, you need to build a wider base first.  You need a solid foundation, one that will support you when the time comes to drive a break 70 miles into a 100 mile race.


Information Security is the same.  If you want to deliver better protection, higher capability, you need to ensure you have a complete and supporting foundation - fundamentals.  If there's cracks or missing sections, there's room for the whole system to collapse under the weight of the stacked stones.

That raises the (obvious) question: what is fundamental to information security?  You have to have Anti-Malware.  And a Firewall.  Mix in some Intrusion Detection, log analysis.

Fact: none of those are fundamental.

Seriously.  You don't need this.

Put down the pitchforks for a moment.  Use of technologies like these are absolutely required, they just don't make up the foundation of a solid information security program.


So what does?


The National Institute for Standards and Technology (NIST) has put together some excellent documentation about managing information technology and information security.  One of their recent products is the CyberSecurity Framework, a product that provides a clear and executable map to measuring information security risk in a practical and illustrative way.


One of the key components of NIST's model is the list of core functions: Identify, Protect, Detect, Respond, Recover.



The Sequence of Core Functions - Each Drives the Next

These are sequential risk-reduction, information security management functions.  Investment only provides mitigation to the right, such investment is best served further to the left.  That means your foundation is the item to the left: Identify.



You can only act on what you've delivered.
Stealing liberally from NIST's documentation, this is what Identify means:

Develop the organizational understanding to manage cybersecurity risk to systems, assets, data, and capabilities

Understanding is fundamental to information security, the level of understanding is the ceiling for any information security program.  And understanding is hard, we always want to fast forward past it to get on to the sexy part of information security (if such a thing exists).

But you cannot secure that which you do not understand.  So let's dive in:



Understand Business Strategy


Information Security cannot operate without alignment with business purpose and strategy.  Use this knowledge to capture (or develop) a list of Threats that apply to the business model, vulnerabilities of the business based on the line of work, then cross to find enterprise class risks.  It is here that technology and information risks can be latched.


This is where we'd capture "Risk Tolerance", and a good place for a short soap box.  Risk tolerance should be a dying term as it's typically used in place of "willing ignorance": a willingness to accept risk due to perception the risks can't manifest (i.e., don't apply).  Risk tolerance should be a business case, financial-driven decision based on potential losses and impact of manifest risk.  But I digress.


This is where the information security program will take root and where it'll find reliance and support as it delivers business cases for risk reduction; the Why of Information Security.



Establish Management Intent

Utilize the knowledge generated in understanding the business strategy to establish over-arching management intent.  This starts with the Security Policy; the policies, procedures, and standards designed to deliver controls that orient to the risks the organization faces. 


The quickest, easiest way to establish intent is to select a control framework and write it into Policy and Procedure.  This becomes a simple process of selecting controls that relate to the risk posture of the company, setting standards within those controls according to the level of risk, and establishing metrics and measurements to enable assessment of compliance to controls.


Intent should also integrate Information Security into other organizations, enabling upstream and downstream delivery of controls throughout the organization.  Information Security has cross-organizational concerns in Vendor Management, Human Resources Management, among others.


The intent of Intent is to establish the rules for how security will operate, aligned to the risks and strategies of the company; the How of Information Security.



Capture Inventory


This isn't a real Datacenter.

This is where the rubber meets the road in the statement "you cannot secure that which you do not understand."  In practical terms, this inventory is the list of stuff that needs to be protected.  There's a lot to think about, but they fall into a few broad categories with the depth of detail driving the maturity of downstream controls.  This is the "What" of Information Security.

Design and Architecture Assets: Network and system diagrams, the "as-built" for the technology system as a whole.

Physical Assets:  There are the traditional technology devices with a few added items.  Servers, laptops, mobile devices, printers, network equipment, security equipment.  Each should be uniquely identified via some electronic means, each should have pertinent information such as responsible part, purpose, and similar.


Service Assets: These are the delivered technologies supporting business functions, such as the HRMS, FMS, ERP, along with smaller services such as Reporting, Project Management, and other solutions.  These should have owning business organizations and/or responsible individuals associated to each.

Integration Assets: Flow diagrams showing the movement of information between services (information systems) and the relationships of business processes to information flow.

Software Assets: The list of approved operating systems and software packages utilized on the environment.

Information Assets: The types of information utilized and where they are intended to be located with owning business organization and/or responsible individuals.

Identity Assets: The complete list of individuals who should have some level of access to the technology systems with information on their role and area of responsibilities.

Access Control Assets: The complete list of defined access credentials for each service and system, and a complete list of the roles and privileges provided within each.

(It's hopeful, and hopefully likely, that the Identity and Access assets are already linked; else, this is low hanging fruit.  Get it done.)

Threats and Vulnerabilities: The last two are a little less palpable but no less important, the list of Threats and Vulnerabilities within the organization.  These are necessary to create a risk profile for the assets inventoried above, enabling decisions on how to deliver protection, detection, response, and recovery in appropriate measure.

Threat Inventory: A list of known potential sources of impact to the organization's technology systems.  This list should be based on the inventory generated above; i.e., threats that are specific to the technologies and services being consumed; and based on how the business is operated, linking threats to parties that may be interested in disrupting the services provided, such as organized crime for retail.

Vulnerability Inventory: A list of known vulnerabilities within the environment.  This should be developed by both technology (scanning) and research, and contain vulnerabilities that impact information security and the application of controls over technology such as environmental and human influences.


It is all about the fundamentals; it's not possible to implement an information security program without having a strong grasp on what needs to be secured, why it needs to be secured, and how it should be secured.  The Identification process provides the knowledge needed to define the necessary technical and procedural mechanisms of information security.


Sorry.  Obligatory.
Without having a solid foundation, vulnerability manifests in cracks, eventually manifesting as failure in controls and, possibly, failure in the information security program.

Sometimes in spectacular fashion.  The pyramid comes crashing down because of a single failed stone.

The investment in time in fundamentals will lead to a more successful program.  Take the time to figure out the gaps, act on them, and the program will be better for it.

No comments:

Post a Comment