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 (https://www.sec.gov/ocie/announcement/ocie-2015-cybersecurity-examination-initiative.pdf). Additionally, the SEC came out with a document illustrating their Examination Priorities for 2017. (https://www.sec.gov/about/offices/ocie/national-examination-program-priorities-2017.pdf)

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.

Pros
  • 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.
Cons
  • 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 (https://www.armor.com/resources/ransomware-service-fuels-explosive-growth/) 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.


Tuesday, January 10, 2017

Disaster Recovery - Is that the same as Business Continuity?

IT departments across the globe discuss Disaster Recovery all the time.  What happens when a system goes down, how fast can we get it back up and running, and how do we handle the data.

Technology - is that all we need to worry about?

The answer is no, there is a lot more.  What about the other aspects of recovering the business?  As of recent, it appears that Business Continuity Planning is getting the spotlight, especially since IT systems are getting more resilient and the ability for workers to access systems outside of the office is becoming commonplace – IT is no longer the biggest problem when it comes to planning for contingencies.

Disaster Recovery & Business Continuity Planning

The way I approach Disaster Recovery and Business Continuity Planning is to look closely at the following:
  •          People
  •          Process
  •          Data
  •          Technology
  •          Facility

As you can probably guess, “Data” and “Technology” are likely covered in the DR plan that the technical folks are writing, but what about the rest? Those are part of the Business Continuity Plan.

Typically, DR and Business Continuity typically fall on the shoulders of the IT department, which is not necessarily appropriate.  If we dissect the remaining categories from above, let’s look at why this is really a business problem:

  • People – What individuals are necessary to keep the business running?  This isn’t referring to the technical staff that keeps the systems up and running, it has to do with the folks actually doing the work to process payroll, input payables, service the customers, etc.
  • Process – What are the employees going to do? Do they know how to do their job when operating remotely? Or with limited resources?
  • Facility – Where are our employees going to go?  Can you fit all the employees required to perform a job function at the location you picked out?  Do you have a location picked out??  Can people work from home?

This is just a little insight on how I approach Disaster Recovery and Business Continuity Planning.


<as published on LinkedIn>

Wednesday, September 14, 2016

Email encryption? Who really cares!

So, I finally took advantage of the low mortgage rates I've seen advertised all over the place and refinanced my house.   I was excited! The bank I applied for the mortgage through was able to do just about everything online, using a combination of Adobe PDF delivery mechanisms and a portal to upload documents required for the mortgage.  

In typical fashion, something broke with their portal and I needed to send one last document to the bank.  My options were to either drop it off at the local branch or send it to them via email.

As it is, with my job, I have many tools at my disposal in order to send messages encrypted through email, but I decided that I really didn't want to use any of our systems at work since I like to maintain a separation between personal business and work.

Hmm, what should I use within my personal email account to encrypt this stuff? Should I zip it and password protect the file?  That sounded like a good idea, but then I started to think of the risk involved with me just sending the stupid PDF.  Do I really care? I mean, what could happen? Is there a chance that some hackers are a just standing by at Comcast headquarters with one of the switches port mirrored, looking for stuff coming off of the residential backbone? I guess it's possible, but what are the chances? Are we really going overboard with this email encryption stuff? Do we REALLY need it?

Unfortunately, in reality, the answer is yes... We do need it.  The biggest problem is that you don't know what's happening between the two endpoints. You can't put your faith in a gut feeling that there won't be any evil happening once the data hits he Internet or that the infrastructure is somehow too big or obscured enough to even allow the capture of your "one in a billion" packets that pass through in a nanosecond.  Since you don't have any control or visibility of what happens between the originator and he receiver, you just can't take that chance with sensitive data assets.

I teach at a college here in Chicago and one of the assignments I have the students in my Information Security course complete is research on something called Room 641A.  Google it... You'll have fun.

(As posted on LinkedIN)

Thursday, September 1, 2016

Data Classification - Who needs it?

As an information security practitioner, there are times when you look at the security landscape for your organization and think, wow, there are definitely some areas we can improve on.  Many of these areas are not necessarily easy to tackle and execution may even seem impossible!

One thing I had always struggled with when working in banking, was data classification. We did have data classification defined, to an extent, but it was really basic and didn’t allow us to make real decisions on investing in technology and security controls.  The bulk of what we really needed to protect was customer information, but was that good enough?

In banking there is a defined segmentation of data that needs protection – customer data.  Putting forth the minimum required effort from a compliance standpoint is really a shortsighted view of a larger data classification need, because there are so many other groups of data that fit into a grey area.  In this grey area lives large quantities of private information, such as the information that human resources maintains on our employees (salary, health care info, etc.), information relating to mergers and acquisitions, employee lists, schedules, bank access codes, combinations to vaults, minimum cash limits…  The list goes on.

How do we classify the sensitivity of this data? It certainly doesn’t fall into the larger category of customer information, but it definitely needs to be protected from exposure.  What’s more, this inadequacy will start to expose itself when looking at initiatives such as DLP, rights management, DR optimization, justifying spend on technology, and now – cyber-insurance requirements.

Take the time to look at how you are classifying data, what types of data labels you are using, and how data classification feeds into larger initiatives.  You may be surprised at how many areas this touches and how it may help with some of the initiatives listed above.

If you need help understanding how Data Classification can help you, or if you are in need of building out a more comprehensive Data Classification scheme, let me know.

(as posted on LinkedIn)