Wednesday, September 27, 2017

A Data Classification Project

In another post, I mentioned organizations not having a data classification standard and associated policy will have a difficult time implementing many information security related controls such as DLP and rights management.  Data classification can also help with DR optimization, justifying spend on technology, and may be a cyber-insurance requirement. Since many security projects rely on proper classification of data, we have seen an up-tick in requests related to helping clients in this regard. 

What does a Data Classification Project look like?

A Data Classification Project assesses an organization’s digital assets to determine criticality, sensitivity, privacy requirements, and to determine a naming taxonomy to categorize the data.

A typical project consists of a series of interviews, research, and tools based discovery to establish the following regarding the data:
·         Location
·         Criticality to the organization (using the typical CIA Triad)
·         Regulations relevant to data

While a full blown Data Classification Exercise could fill a book, I'll attempt to condense it down in this post.

Location of Data and its Risk

Interviews with business unit managers as well as the technical staff are coupled with a tools based discovery effort to identify all of the repositories containing data.  These repositories will start with physical data containers such as hard drives, SANs, NAS devices, cloud providers, etc., and will ultimately identify files, databases and applications.  Once there is a mapping of the data locations, we will start to group the data by risk to the organization.

The following table illustrates an example of the risk each discovered data element has to the organization and how it might be calculated:

Data Element 1
Data Element 2
Data Element 3

Data Leakage, Theft, Disclosure

Data Compromise, Manipulation

Failure of system, Comms, Deletion
Risk Score

Data Labels and Classification

Once the data is identified and ranked, a naming taxonomy will need to be decided upon.  This is when data labels will be used to mark data so the appropriate controls can be applied – whether they are automatic or manual, technical or otherwise.  Most people have at least heard of one of the federal government’s data labels – “Top Secret” - a very high level of sensitivity of information, only allowed to be viewed by individuals with a “Top Secret” clearance, or higher clearance.  The “Top Secret” designation is the data label, which is applied to documents, emails, etc. and the classification is the understanding of what information falls into this category.  While regulated entities such as healthcare and banking already have data protections defined, an organization will still need to come up with a labeling scheme.  Carnegie Mellon University has a great example of how their data is labeled and classified:

Restricted DataData should be classified as Restricted when the unauthorized disclosure, alteration or destruction of that data could cause a significant level of risk to the University or its affiliates.  Examples of Restricted data include data protected by state or federal privacy regulations and data protected by confidentiality agreements.  The highest level of security controls should be applied to Restricted data.

Private Data - Data should be classified as Private when the unauthorized disclosure, alteration or destruction of that data could result in a moderate level of risk to the University or its affiliates.  By default, all Institutional Data that is not explicitly classified as Restricted or Public data should be treated as Private data.  A reasonable level of security controls should be applied to Private data.

Public Data - Data should be classified as Public when the unauthorized disclosure, alteration or destruction of that data would result in little or no risk to the University and its affiliates.  Examples of Public data include press releases, course information and research publications.  While little or no controls are required to protect the confidentiality of Public data, some level of control is required to prevent unauthorized modification or destruction of Public data.

Once a project like this is completed, it will become much easier to implement effective protective controls on the appropriate data.  I usually find the exercise also sheds light on the sheer expanse of data an organization maintains.  When management is given visibility into the amount of data, backed up by numbers showing the risk the data poses to an organization, decisions can be made and budgets can be created to ensure the protection of data is appropriate.


Friday, August 4, 2017

Starting the Azure Information Protection Conversation

While Azure Information Protection (AIP) may not be the most popular product in the EM+S product suite offered by Microsoft, it is certainly gaining ground because of its tracking and control capabilities over the movement of confidential and sensitive information externally and within an organization. Many organizations own EMS E3 or E5, which come with AIP, thus giving them the ability to manage the rights of documents and email, but the majority of them aren’t using this technology.

Demonstrations of AIP’s technology are amazing, and it’s exciting to see the possibilities with tight control over organizational data. In the haste to turn on the technology however, many AIP implementations stall, fail or just don’t get utilized. Why? It’s simple – the business conversations get bypassed.

Introducing rights management concepts and capabilities that AIP brings to an organization is a challenge because of the prerequisites necessary before getting started with AIP – namely Data Classification and Data Labeling. Since conversations surrounding these two areas are business oriented, communication tends to break down because IT is focused on the technology, and there is nobody to broker the conversation with the business.

Since data classification and data labeling are two keys to understanding how AIP will be architected let’s take a look into how these conversations will set the stage for making an AIP roll out as smooth as possible.

Data Classification and Data Labels 

When I think of data classification, I think of one of the federal government’s highest classification schemes – Top Secret. Most people have at least heard this phrase or have seen references to this in the movies. Do you know what Top Secret means? You likely have a really good idea – it’s a very high level of sensitivity of information, only allowed to be viewed by individuals with a “Top Secret” clearance, or higher clearance. The “Top Secret” designation is the data label, which is applied to documents, emails, etc. and the classification is the understanding of what information falls into this category. Regulated entities typically have classification schemes already defined. Healthcare has PHI (Protected Health Information) and banks have NPI (Non-Public Information). Each of these labels have regulations and standards defining what falls within those classifications and how to handle the data.

 Another good example of classification is “Internal Use Only”. The classification indicates that documents with this label are to only be used internally and viewed by individuals within the organization.

I’ve been involved in many data classification projects with my clients, where we help them determine sensitivity of a particular data set and what protections should be placed on them. Most regulated organizations understand what data classification is, but even unregulated companies have an understanding of what data constitutes the “crown jewels” and we likely know where it resides. This is certainly a prerequisite for an AIP implementation.  

In a typical AIP alignment workshop, the workflow looks as follows:

Within this workflow, we start by looking at any existing corporate data classification methodologies currently in place. We can either discover this by doing a data analysis and strategy session with management, or it can start by exploring the regulatory requirements placed on the organization. As pointed out earlier, most regulated organizations have data classification standards already defined, but, as we will see, some of them may need to be enhanced and there may be cases for adding additional labels.

The next step is to look at the controls AIP can place on documents, email, SharePoint and OneDrive repositories. As we explore the AIP control-set, there will inevitably be additional ideas on how information can be protected. Here is a breakout of possible controls within AIP:

A common question we are asked with projects like this is: What we do with all of the other controls we have over data and how they will be used as a complimentary control-set, or as back-stop controls. Once AIP is implemented with the data labeling and categorization defined, there will never be 100% adoption unless you are on the P2 licensing where you can automate the classification and labeling of documents meeting certain criteria. With the P1 license, you will be relying on the user population to take the necessary steps to label each of their emails and files accordingly. This supports the need to keep many of the backstop controls listed below, in place:

Implementing AIP is not as easy as flipping the switch. A real AIP project will consist of pre-implementation planning and road-mapping. AIP is usually piloted at an organization, and training for the new capabilities is essential for the project to be a success. If you are thinking about AIP, or other components of the EM+S product suite, let me know how I can help!

Monday, May 1, 2017

Migrating email to the cloud as a security strategy

I feel like this article was actually written about 5 years ago, but there are still many organizations that aren’t leveraging a security rich cloud-based email system such as Office 365. Let’s face it, notwithstanding hard-dollar cost reduction, rarely is there a business need to switch email systems or email providers. Migrating email to the cloud is no different – unless the cloud has a compelling story.

In the recent past, I have found that it has been consistently difficult to find financial justification for moving email services to the cloud. Many times, it is hard to prove that the investment will pay off and quite often, it ends up simply being more expensive. While soft costs are something that should be considered, many small businesses don’t put as much weight in soft costs as they do hard dollar savings, so gaining any traction on these types of projects are tough.

Why then, should we be considering such a move? Risk Reduction!

I have seen many implementations of email systems - they typically consist of a cluster of servers with a disk array attached. Redundancy is accomplished with a combination of application features and tools based replication. … and, don’t forget about backup. Disk-to-disk and tape still exist to supplement grandfathering retention requirements. Add on the requirements the need for eDiscovery and true mailbox archiving, and you have yourself quite a robust system that likely grew incrementally over the years. Considering the already large footprint of your typical email system, we haven’t even started discussing email encryption, data loss protection, mobile access, storage sprawl, and the various spam and malware mitigation that is attached to most systems. When it comes right down to it, the on-premises email eco-system is huge, has a lot of moving parts and is difficult to manage, which makes it clear that it poses a major risk to the organization.

Many IT folks still running in-house email systems might call it heresy to suggest that we should entertain a cloud-based a strategy to enhance security and reduce risk, but when you take an objective look at the email mess that exists in many organizations, it only makes sense.

Cloud advocates like to tout the many benefits of the cloud, whether it be the elastic nature of cloud services or the availability of immense computing power at your fingertips, but lately its becoming a conversation of capability and simplicity – two very important components of a security strategy.

Some of my duties as a consultant have me tasked with running cost/benefit analyses, forecasting spend and justifying capital expenditures. As cloud technologies continued to mature, it became clear that there are many features offered in cloud-based email offerings that are either not available with in-house email or that those features will add cost and complexity to the already complex environment.

Here are some examples of what can be accomplished (or consolidated) with Office 365 and Microsoft’s offering in Azure:
• Self Service Password reset
• Data Loss Protection (DLP)
• Mobile Device Management (MDM)
• Email Encryption
• Multi-factor Authentication (MFA)
• Archiving, eDiscovery & Retention
• Rights Management (RMS)

How many of the technologies above do you have in your on-premises email deployment? How many vendors does this represent?

Don’t get me wrong, cloud-based offerings aren’t for everyone. Like any initiative, a healthy risk based review should be incorporated into any potential project, or corporate initiative. There are also challenges with the cloud and hybrid environments, but understanding these challenges and exploring opportunities (reducing risk by reducing complexity, taking advantage of advanced security solutions and consolidating vendors), will likely lead you toward identifying cloud based email, such as Office 365 as a great approach for your organization.

Friday, March 17, 2017

Manufacturing meets Security

If you are a government defense contractor and you receive controlled unclassified information, you must comply with NIST SP800-171.

In April of 2015, NIST published the first public draft of something called SP800-171 which described requirements for protecting controlled unclassified information on non-federal information systems and organizations. The government also published regulation (DFARS 252.204-7012) that states that any entity that collects, develops, receives, transmits, uses, or stores defense information in support of a government contract must abide by the guidance in SP800-171 – with a deadline of compliance to happen by December of 2017. That’s right around the corner!

What does all of this mean?

There are 14 categories of compliance and each one has numerous objectives that must be achieved. This means that there are various processes, procedures and probably systems that you will have to implement to achieve compliance with this mandate. There is a lot of guidance on the internet on how to comply, but much of this information is obscure and difficult to read. Putting together a game plan for compliance can be a daunting task – especially if you don’t know how to comply with items such as Performing a Risk Assessment or Create a Vulnerability Program.

Let me know if I can help - I'm continually working with organizations that have compliance challenges and helping put together strategies for understanding where the gaps are and executing projects to close those gaps.

Wednesday, March 1, 2017

Examinations focusing on Cyber for brokerage and securities firms

The banking industry has traditionally been the poster child of regulation. I’ve been dealing with federal and state regulators since I started in the industry back in the early 90’s. I can remember one of my first “IT Examinations” back in 1995 - The examiners at the time were more interested in getting up to speed on the rapidly evolving technology than they were with being able to provide direction to the bank. Those days are definitely over and many very talented and skilled examiners now exist at every agency that regulates banking.

Review of technical controls back then may have been a bit of a joke, but nowadays, it’s no laughing matter, which is evident by the ramping up of cyber-security by the examination body that regulates brokerage and securities firms – the OCIE.  While the OCIE has always been in place as an examining body of the SEC, the effort spent on IT was marginal at best - That is about to change.

Last year around this time, the OCIE came out with a Risk Alert that stated that they were going to be focusing  their efforts on cyber-security and published a document that illustrates what they will be looking for ( Additionally, the SEC came out with a document illustrating their Examination Priorities for 2017. (

Glancing through the appendix of the first document, the traditional banker wouldn’t bat an eye, but if you are a small securities firm, this is something that will likely give you pause. It discusses such topics as periodic assessments, vulnerability scans, and policies. These are not typically a problem and can be put in place rather quickly, but what about nebulous areas like data mapping, data classification, risk management, vendor management and incident response? That’s a heavy weight on the shoulders of a small IT staff – especially if most of those terms are unfamiliar!

The company I work for can help you put together a strategy for understanding where the gaps are and executing the project to close those gaps. Compliance initiatives are something we work with continually across many industries. Contact me for more information or if I can help in any way.

Wednesday, February 22, 2017

So, you want to be a consultant?

If you would have told me that I was eventually become a consultant, I wouldn't have believed you. For years, I have been known as a banker.  I started out working in a bank when I was just 16 years old and have been involved in various aspects of technology, security and compliance within banking ever since.

... that is, ever since I quit back in 2012!

That's right, I left the banking industry and went into consulting.

Its been my experience that most individuals go into consulting in pursuit of experience, eventually moving to the enterprise space. The move I made was quite the opposite.  I had a successful career in technology and security and was looking for a change.  Most banks had emerged from the banking crisis, but the one I was working for was continuing to struggle.  

In the spring of 2012, I started in consulting and I never looked back. Quite frankly, its hard to believe its been 5 years already (as of this writing).

Since I've been in consulting, I have had many folks ask me how I feel about it.  The vast majority of conversations I have on the subject find that people are intrigued about my move into consulting and are considering it for themselves, sparking interest and ultimately asking:  How do you like it?

As with anything, there are pros and cons, so I took a moment to jot down some of them.  I'll add to the list as I think of more, but for the most part, I think I have them all covered. Thankfully, the pros out weigh the cons in my mind by a long shot.  Keep in mind that this has been my experience with working at only two small consulting firms in Chicago.  Also note, I didn't include points that are firm specific like expense accounts or larger issues such as travel.  I kept it focused on pros and cons to the actual practice of consulting versus enterprise.  Finally, understand that I am a pure consultant.  I am not a managing director, or higher level that has responsibility for revenue - I'm on the execution side.

  • Expanded Network - While I was in banking, I made a lot of contacts - so I thought.  I was locked in to the small world that I knew - and I didn't realize it. Once I moved into consulting, I worked with so many companies in various verticals, my network grew 10-fold in just a few years.
  • Diversification - Working at the bank, I knew just about everything about everything in banking - specifically related to the bank I worked at.  Looking back, I was really a one-trick-pony.  In consulting, I am working with health care, manufacturing, professional services organizations... the list goes on.  Learning how various industries function has enriched my understanding of the realm of IT, InfoSec and compliance.  
  • Learning opportunities - I'm not talking about training, I am talking about learning about how different industries work!  Similar to diversification, I am gaining quite an understanding of how companies interpret regulation, how its applied, and the multitude of technologies in use out there.  Sometimes I feel like I've touched it all - then we get a new client with a different flavor of technology,  process and procedures.
  • Politics - If you don't like the people you work with, you're pretty much stuck with them until they quit... or you do.  In consulting, you know that all projects have a timeline - that is an oddly comforting metric.  Don't get me wrong, there are certainly politics that need to be dealt with internally, but if you are typically client facing, these issues aren't as much of a big deal.  
  • Budget - I remember the days of not being able to move initiatives forward because of no budget.  Not any more!  If the client doesn't have budget, we move on to the next client. Granted, there are plenty of engagements that I work on where we try to help the client meet certain budget benchmarks, but its nice not to be fully responsible. Conversely - see "Budget" in the "cons" section.
  • Helping - Lets face it, most of the time you are being called in to help.  You are wanted.  It feels good to help people and this is probably my biggest "pro".  Its hard to get this feeling while being a cost center to an internal IT or InfoSec Department.
  • Profit center - Speaking of cost center - You are now a profit center for your company - you are a valuable asset.  IT and InfoSec is typically a cost center.  While the IT and InfoSec folks in the enterprise have a lot of value and are often underrated, the business still looks at them as a liability.
  • Sales/Account Managers - These folks are responsible for bringing revenue to the company, and there are challenges with that as you will see in the "cons" section below.  The best part about their role is that they have to clean up complication, discuss overages, and all of the many sticky situations that may come up.   They have a tough job in this respect and I am glad I don't have to do it.
  • Ownership - As a consultant, for the most part, you will be brought in to solve part of a puzzle, or document a road map or strategy for doing so.  Most of the time, you will never see this fully play out.  Its hard putting a lot of effort into a game plan, strategy or road map and not seeing how it all works out in the end.  Your sense of ownership will be missing and will need to be filled in other ways.
  • Disposable - I've done some of my best work as a consultant.  I've worked for hours on a client deliverable to make sure it is perfect only to realize that it won't be executed on.  There are times where you may get pulled from an engagement by a client - They either lost funding, or something else happened.  They can pull the plug on a consulting engagement at any moment. I remember one engagement - I was doing security leadership work at a medical center and making major progress on a number of initiatives when they hired a new medical director.  We were pulled in favor of another consulting group that was close with the new director.
  • You have to be "ON" - Sure, there are moments where you get a break or are between engagements, but for the most part, you need to be studied up on the latest stuff, and have to be able to talk about it with authority.  If you are not able to deliver information with strength or don't exude confidence, you will fail as a consultant.  While there is certainly room for the occasional "let me check on that", by in large, if you are called in as the expert, you need to have the answers.  This is pressure some aren't ready for.  Imagine being called into the board room every day to explain something / your position / etc. That maybe an extreme example, but not far from the truth.  This goes for pre-sales motions as well as actual consulting.
  • Going in cold - You have to go into an environment - some of them quite complex - and quickly slice and dice your way through the information being thrown at you. You will often be required to make decisions quickly on that information and start executing on that plan.  Some people thrive on this, some are intimidated and can't operate in this manner.
  • Budget - There are times when a project gets scoped incorrectly.  Sometimes projects are just a complete disaster and the client holds your feet to the fire to get the project done in the budgeted time. These are difficult situations that you will be in the middle of.  You just have to try to make lemonade with lemons and do what you can without risking your reputation. 
  • Tracking Time - You are a billable resource.  You will be required to track your time - every day.  Sometimes this feels like being micromanaged, but if you look at it - the only way to get paid is to send an invoice that has your time and notes attached. Its a necessary evil. If you ever worked with a lawyer and got a bill from them - time tracking for a consultant is the exact same thing.  The up-side to this is that management never asks what you are up to and in reality, you aren't micromanaged.  Reports fly by my manager's desk and if he sees anyone that is less than a certain percentage of billing, that's when conversations happen - Those conversations typically happen with the Project Managers and Sales Staff.
  • Sales folks - You will come to realize, that most sales people are great folks.  Your observations from outside the consulting practice will also be confirmed:  They are driven to make sales - that is their number one objective.  It may be accomplished in any number of ways, and some of these ways may not mesh with how you think the client should be approached.  In some cases, you may even have to do some "clean up" because of a poorly sold solution.  

Thursday, February 9, 2017

Ransomware - Should I pay?

Ransomware – Should I pay?

The “right” answer is – No, you shouldn’t pay the ransom. This is similar to the stance the government takes when dealing with hostages. In principle, not paying ransom diffuses the whole process – the bad guys don’t get funded and the effort is for nothing.

… but, does it ever make sense to pay the ransom? 
Consider this - I just read an article by Armor ( that said the average ransomware demand is about $679. Depending on the size of the company, downtime, and number of employees affected, recovering from a ransomware attack could easily take a day. We need to ask ourselves, does the cost in time, effort, loss of productivity, and possible loss of work for a day exceed the ransom demand? At a low, low price of $679, it may be a no-brainer.
While it is great to take a stand and not let the hackers get away with this, it is ultimately a business decision – one that may make sense.

What if they don’t give you the unlock key?
Depending upon the ransom demand, the decision to give it a try may be relatively simple, but you must decide whether the roll of the dice is worth it. 
I'm willing to bet they will give up the key. Why? Because if hackers get a reputation for not producing the key, guess what – nobody is going to pay the ransom demand and the hackers aren’t going to like that very much. They want to keep this party going for as long as possible!
In short, you need to make a business decision.  If the dollar figure is small enough - Pay the demand, chock it up to payment for lesson learned, and tighten up your organization. The amount of money required to restore operations and the cost of downtime may easily usurp the dollar figure for the ransom. Not sure if you have all of the correct security implementations in place? Do you know how Bit Coin works? Do you have a game plan for when it happens? I work for a great company that can help you with that.