Thursday, March 24, 2016

Assume Breach

Assume breach, or not, may be a false dichotomy - a binary error in our thought process.  However, if the past is any indicator, and it’s implied to use it as such, one can only come to the conclusion that assume breach is the most rational and productive course contrasted against a mentality which assumes you haven’t been breached, are not breached, and will not be breached.  In the spectrum of infosec practice, assume breach matches well with management standards and regulations, so how does this get lined up to where it has a useful synergy with our operations?  It provides an excellent audit tool from a functional point of view.
When we assume breach, there are three distinct times that correlate to different activities, albeit with some overlap.  Past, present, and future breach are more than just considerations to keep our egos in check and our thought processes honest.  There are specific goals that we can align to activities and, as stated above, these will map directly to compliance artifacts.  Each one presents certain priorities differently and requires a different approach to the problem.  This brings with it a hierarchy that meshes with infosec operations.

Past Breach

You’ve been breached in the past and regardless of whether the breach is still ongoing, there are some steps that need to be taken and include some dependencies.  The specific activities we’re looking at here involve incident investigation and those associated activities.  What unauthorized activity took place?  What files were accessed/modified?  The dependencies for this include having an asset evaluation policy, or criticality policy, that outlines how your organization defines asset criticality and maintains inventories for where they are located.
Additional activities include physical network asset locations and inventory as well as identification of proper logs, their locations, and appropriate query examples (have they been appropriately configured in the first place?).  What impact did it have on the organization (don’t forget qualitative)?  Use the information gained to review the failures that led to the incident such as insufficient standards, procedures, and guidelines (SPG), or myriad other access issues (when did you last do a user access review?).
Without the ability to have visibility into a past incident, you have absolutely no hope of detecting a current or future incident with enough resolution to action.  Past breach is a foundation to build security from the ground up into a functional group that provides measurable improvements and mitigation.

Current Breach

Once a past breech mentality has been effected, it’s time to consider the actions around a current breach.  Is there sufficient visibility into network traffic to identify abnormal behavior?  As a dependency, have you executed use-cases to establish what is normal so you can discriminate that which is abnormal in the first place?  What impact is this currently having on the organization and can you mitigate it and recover?  Who knows where your backups are, how recent they are, and how long it will take to recover?  Is your business losing money because of a disruption in services/access and are they adequately prepared by a BCP process they’ve been tested on to attempt to continue doing business during the incident?
Do you have enough visibility to identify malicious entities and map them internal to external in order to cut off the attacker?  Do you even want to cut them off, or let them continue to believe they are undetected so law enforcement can get involved?  What are the regulations for your industry around breach reporting?  Is your legal and media team prepared to release a public statement?  Do shareholders get notified?  Do you even know how to contact the proper law enforcement in such an event?
As you can see, the implications of a current breach can stretch deep into not only the business operations, but also into the top levels of management and policy.  Infosec managers reading this can probably already see the writing on the wall.  Only a comprehensive and purposeful approach will prepare an organization to react to a breach.

Future Breach

Considering all the work that has come before, you now have the ability to properly address a future breach.  Here you can implement HIDS/NIDS, SEIM, encryption, and more, but one of the most important but least recognized is threat intelligence.  With proper risk and vulnerability assessment through research and threat intel, you can get a much better grip on likelihood based on the threat landscape and reported attacks.  A dialed-in likelihood is absolutely crucial to developing an appropriate risk profile, from which flows the priority on asset and operation mitigations.  It ensures that your matrix is actually tuned and working right.
From here, you can develop gap analysis and track progress toward compliance while being able to demonstrate meaningful improvements to the organization.  If you can’t show value, you’re failing to perform.  All lessons learned and actions taken at the previous two steps can now be used as a means to identify other shortcomings as they arise, but the base point still stands as I wrap this up:


If you do not assume breach, you’ve already completely failed in your mentality and approach to information assurance and security.  If there’s no threat of breach, there’s no cause for risk management.  The fact that breaches happen is the very heart and soul of why we do what we do and why there is a market for our talent in the first place.  To deny assume breach is to deny the very existence of our profession and its purpose.  It makes absolutely no sense to do so.  Without assume breach, many of the activities that we perform in the Infosec role are trivialized and boiled down to nothing more than forced regulatory and compliance burdens.  We’ve been in a rut with at least a decade of deniers - people who still claim that it’s possible to create a secure environment.  It’s not possible.  You WILL be breached and the assumption is far from mere pragmatism.  It’s a statistical inevitability.  By starting in the past and moving forward, you align with the inside-out approach to clearing out past and present anomalies, with the eventual goal of preventing them altogether.
By assuming breach at each of the three time frames, we get a chance to break down the vast infosec scope into three interrelated groups which help to maintain a priori focus on each task above and beyond that of compliance alone.  Why are you doing your job?  Because breaches.  When do breaches happen?  Past, present, and future.  Structure it as such and it will help you create a plan of attack and stay focused on task when building your security.

Saturday, August 30, 2014

More on the hiring debacle

Violet Blue wrote a security blog topic here at ZDNet titled: Cybersecurity's hiring crisis: A troubling trajectory.  Such an enticing lead, I could hardly resist.  It's a topic near and dear to my heart, as I am one of those people who had to fight tooth and nail to break into a field that claimed it was begging for people.  I know I'm definitely a newcomer, but that doesn't mean I'm not capable of seeing the obvious.

I certainly understand that the article is specifically speaking to the shortage of hackers, but it almost seems to wrap the confines of the Information Security profession within that myopic boundary.  Infosec is much bigger than hackers, and the entire profession suffers from the similar issues.

I'm not going to waste your precious time by preaching to the choir.  We know what the problems are.  However, when we break them down to the core causes, they tend to be:

#1 - Companies want top-tier talent at bargain-bin prices.
#2 - HR has no idea what the job entitles and must rely on outside descriptors that could be suspect.
#3 - No formal continuity to agree upon industry-accepted roles.
#4 - Inability to establish standardized descriptors due to #3.
#5 - Laser-like focus on specialized skills and experience.
#6 - Holding #5 against potential applicants because they're too specialized.
#7 - The failure to realize the full scope of infosec as a profession.

I could go on, but that is a sufficient sample of what I see for the point of this blog.  Most of it stems from ignorance of what infosec is and how to go about hiring.  As Violet emphasizes in her post to quote Chris Hoff of Juniper Networks, "...'Security' is still a reasonably young 'profession'...".  I would argue it's still a fetus, especially compared to the business unit it must integrate with.

I have stated that I believe that for infosec to begin to address these issues, we have to organize as a community to put forward the initiatives that can correct these problems.  We need to agree on what we think are reasonable job skills and roles, or particular traits, for specific jobs.  These must come from our industry, because nobody knows them like we do.  Are we waiting for someone else to do it for us?

Obviously, I am a role-based advocate because I view it as the most effective means to categorize the many different job positions and specialties into a high-level view that can be easily managed and understood.  Reasonable expectations that can be agreed upon by both infosec and business are the first key to correcting these problems.  There are big differences between units such as the technical, governance, and consulting units.  While some people may be awesome at hacking, they may not have the slightest clue how to develop a framework to integrate security metrics to business processes.  Our entry points to the field must reflect the incredibly diverse pool from which we come.

Also, ladder progression is very muddled. While someone most definitely can someday become a CISO after working up the ladder from Help Desk, it isn't an absolute prerequisite.  There are high-quality degree programs from highly reputable institutions which can help people perform to a high level, as an analyst for example, with minimal field experience.  The biggest hiring issue is that the infosec field is highly porous.  It's less like a ladder, and more like first-come, first-serve concert seating.  Yet we have the business industry trying to manage hiring the traditional business way and that just isn't working.

Many of the constructs that we deal with in infosec run counter to the long-held ways of doing business.  One of the big challenges that we naturally face is getting manufacturing-model ingrained executives to accept a maturity-model, or in getting waterfall thinkers to be agile.  We are battling long-held traditions and methodologies and trying to combat them for the sake of adapting to the new realities of the global digital business landscape.  This fight is pervasive to all aspects of business, why would it not also rear itself in the hiring process?

If we want to combat these problems we need to be excellent communicators and advocates, but we also have to take the lead on fixing them as well.  Nobody is going to do it for us.  As Brian Engle concisely tweeted, "I think we are far from defining the solution..." and, "Time to stop debating and start closing the gaps."


Wednesday, July 16, 2014

Social Engineering Clients?

Rafal Los made a great post discussing how we think about security seals that are displayed on websites.  Basically, the gist of it is that these seals don't make anything more secure in their nature, but they show clients that the company cares about their security.

Well, in the manner that it should, then yes, but practically, I see a problem when we go even deeper into the discussion.  You've all seen those websites that say their product is endorsed by, or shown on, 50 different TV channels, programs, or radio stations, and they prominently display the logos for all to see.  The issue is that some of these are making fraudulent claims and they never were "as seen on TV".  The site sure does beat its chest to make people think so.  It's social engineering.

If I go to a website and it has a nifty little seal on it that says something about security, I'm thinking, "yeah OK, whatever".  That's because, in all honesty, anyone can make a seal and slap it on a website.  A seal alone is nothing but an image and it tells us nothing about what is being done for security behind the scenes.  If anything, a company could outright lie about having security in place and the client wouldn't be privy to know otherwise.  Isn't this social engineering?  Is it not creating a trust issue?

How do we move forward?  For one, security professionals should stop it with the sensationalism and hyperbole.  "Hacker Proof" is about the most irresponsible thing you could put on a seal.  It spreads this false notion that something can be 100% protected from hackers, and that is nothing short of insanity.  I would expect a company of security professionals to know better, but I suspect that this was more of a business move than a security move.  Someone, somewhere, probably protested it profusely and lost to marketing.

Secondly, there is only one reasonable and verifiable way to handle this.  Compliance.  Organizations should meet compliance standards to which they can host an appropriate seal that doesn't set some kind of unrealistic expectation.  Organizations should be able to provide compliance organizations with actionable proof that they are meeting their compliance obligations, and be able to provide a Letter of Attestation to any client who requests it.

Exactly what security measures are being taken should be kept confidential and no company should expose that information.  So, it needs to be verified in a way that maintains obfuscation.  That leaves us to reasonably assert that official compliance in a responsible manner will help us see at a glance which companies are doing the right thing and which aren't, without exposing exact security measures.  It ensures real trust without setting unreasonable expectations.  Doing otherwise is exactly the opposite of creating trust.  It's creating false trust and continuing to propagate the false notion that security can be 100% secure.

Thursday, June 5, 2014

USAA Bans Google Glass

USAA Bans Google Glass

USAA, a provider of insurance and banking products to veterans like myself (love my USAA!) has banned Google Glass from being used by their employees.  Rafal Los thinks this is a sound and logical idea, and I agree.  However, I also think that this is only a temporary stop on the tech train.  Technology is emergent, and simply banning it or ignoring it is not a viable long-term solution.

USAA seems to specifically target head-worn devices -

  • Information Security
o    Prohibit head-worn smart devices for all employees when in meetings (except when worn for demonstration / research purposes)
o    Prohibit head-worn smart devices for member contact employees and employees with access to portal / member data when at workstation.
  • Physical Security
o    a
o    Prohibit the use of head worn wearable technology that could inhibit an employee’s view while walking in the workplace environment.

I can understand this to a point, because something worn on the head would have a greater field of view than most devices.  What I don't understand is their reasons listed such as, "Malicious or inadvertent audio recording - Malicious use of camera / image capture - Malware conduit - Data leakage - Behavioral risk".

In other words, everything that most modern mobile devices (including my wife's 3DS) can already do.  No, they're not head-mounted, but as for the concerns of audio, malware vectors, behavioral, etc...  these are already traditional risks associated with the use of cell phones, tablets, and every other type of mobile device we're seeing in the workplace (including laptops, which often have a built-in mic and camera).

This does seem like a smart move temporarily, but it almost smacks of prejudice.  In the short term, yes, let's not take the risk, but we can't ignore it forever.  We need to start conversations about how we want to handle these devices and what kind of mitigation that we can put in place for them, because emerging tech isn't going away and the ostrich approach is not a viable solution.

Friday, February 28, 2014

Applying Warfare Strategy to InfoSec - Part 1

Over 2,500 years ago, a book was written on bamboo strips that would become treasured by rulers, strategists, and later coveted even by business leaders.  Sun Tzu's Art of War is a keen source of wisdom on warfare.  What is warfare but conflict?  This is why the book has seen the success it has.  Its principles underpin the very foundation of thought in how we approach conflict.  Sun Tzu, or whoever wrote Art of War, understood that the weapons of war would change but the concepts of conflict and the basis of strategy would not.  Or so he thought.

Today, however, Information Security is very much a different kind of direct conflict - the relentless blackhat onslaught with the whitehat on defense - and it doesn't allow several of the book's teachings to apply because of the unique circumstances.  Regardless, there are some noteworthy items of interest that can, and should be, used by InfoSec practitioners, and I will cover them in a series of short blog posts.

#1 - Know your enemy.

In Chapter 3, "Attack by Stratagem", Sun Tzu lays out the idea of strategy as a weapon and gives examples.  The closing paragraph of the chapter is the most relevant, in which Sun Tzu conveys the saying -

"If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat.  If you know neither the enemy nor yourself, you will succumb in every battle."

How well do you know your enemy?  How well do you understand exactly what your enemy will try to do and what motivates him or her?  Perhaps you understand yourself - your motivations, your capabilities, your knowledge, and your tools, but that isn't good enough.  Not by a long shot.  Compounding the issue is that it is often difficult to even realize with any certainty who the enemy is.  We define the enemy and the likely attack vectors they will use based upon their motivations.  For example, hactivists are likely to try to DDoS you or deface your website, while espionage experts will attempt to penetrate your authentication to access your storage.

The key to understanding the "enemy" in InfoSec is understanding what you have that someone else may want and then work out the methodologies that are likely to be used based upon those observations.  This is why proper criticality assessment, classification, and isolation (AC), are crucial components, not just of a security posture, but as a part of understanding who you are as a combatant.  In addition, understanding the different primary profiles of malicious attackers is a key component required to form proper abuse cases.  Policy and security implementation must flow from these informants if they are to be meaningful and useful to the organization.

Saturday, February 22, 2014

Hunting InfoSec Werewolves

I once was hired by an organization to evaluate and update their IT solution.  One of the first issues, that desperately needed to be addressed, was that of physical security.  The server room was a main traffic area with random employees walking through all day long and it was never independently secured.  The server rack door was also not physically secured.  One of the first recommendations I made was to pull the carpet out of the server room and physically secure it.  I was met with resistance and the reasoning was, "It hasn't been an problem before, so why is it a problem now?"

This is the kind of mentality that gets organizations breached.  It's not just a simple isolated case.  In fact, it is a product of a mentality that IT (especially InfoSec) should have to justify solutions that are accepted in every other form of business, and even personal life.  For example, I could ask, "Have you ever lost your home to a fire?"  If the answer is, "No", then I could say, "Then why bother installing fire alarms and keeping fire extinguishers?  If it hasn't been a problem before, then why is it a problem now?"  The idea that nothing bad has happened before, therefore it is not likely to happen in the future, is one of the most obvious logical fallacies.  To be sure, the longer something doesn't happen to the organization, the greater the odds are that something will.

But even if we do manage to convince the stakeholders of the seriousness of the problem, we often run into the issue that they then do not understand how to go about solving the issues.  Often, with executives, they want a silver bullet.  If there's a problem, throw some money at it, and buy something shiny that promises to fix it.  The problem with that scenario is that it is proven to not work.  Hardware and software, applying band-aid after band-aid, is not going to stop the security hemorrhage.  Fielding more and more weapons in an attempt to overkill the enemy is a wasteful and costly tactic that has been proven throughout history to be virtually useless.  Tools, such as hardware and software, are the weapons of the war, but it's the wetware, the people, that must develop and deploy the strategy that puts the tools to their proper use.  Tactics without strategy is neither tactical nor strategic.  The two must work in concert to be effective.

The best way to solve this problem is to communicate the issues to senior stakeholders so that they understand these concepts.  It's time to change the paradigm and move forward because what is being done now is clearly not working.  This is why T-shaped architects and employees are so vital at this time.  We need people who can communicate and translate across disciplines to effectively disseminate critical constructs to shape the future of InfoSec for decades to come.  First, we have to stop looking for silver bullets.  They don't exist.  We have to stop playing to the naive notion that if we simply produce more robust security products that all our problems will be solved.  It's time to get people involved in asking the hard questions, and collaborating to come up with effective strategy that will empower the next generation of digital life.

Wednesday, February 19, 2014

Facing down the hiring demon.

The discussion on Twitter has ignited in regard to the issues with the hiring process for entry-level InfoSec people.  Obviously, I have some skin in this game, but please bear in mind that my obligation isn't just to my family, but to the community which has had to go out of its way to try and help me.  Bottom line:  It shouldn't be this hard to break in.

So first, let's examine why it is difficult to break in.  As pointed out by Rafal in his blog post here, the first issue that arises is unreasonable expectations.  Expectations should match the position, not the one that is one notch higher than it is.  For example, Rafal states, "It seems that every entry level gig I've been able to dig up... require ~2 years experience and a CISSP. Say what?  ...What definition of entry level does that match?"

Point taken.  It doesn't match and that's the problem.  The expectations are too high.  I'm not saying that the industry should have low standards - that is quite the opposite of my attitude toward it, but one can have high standards paired with reasonable expectations.  Examine the very definition of "entry-level".  Anyone who requires experience of someone who has none and can't get it because everyone requires experience before they'll give it, then they are effectively cutting themselves off from new recruits, perspectives, and ideas.

As a military veteran, it is equally absurd to me to consider the parallel of the military requiring fresh recruits to already have at least two years of combat training to get in.  If our military did that, how long would it be before it could no longer sustain itself?  Yet this is exactly what InfoSec is doing to itself and trying to feel justified in doing it.

So why is that the case?  Obviously, organizations want value from their investments.  That's a no-brainer.  But what I think many organizations are failing to understand is that InfoSec people span a vast range of skills and roles and it's not experience that matters in a new recruit nearly as much as the intelligence of that recruit.  Tools and techniques change and always will, so why would an organization put more consideration on whether someone is highly familiar with a particular tool or group of tools, than emphasis on the thought-process and mental capacity of the candidate?

Sure, that makes sense, but that's not realistic in our current situation and here's why.  Organizations don't want to train people or give experience to new recruits for two reasons.  Number ONE - Organizations want to hire someone who can perform on day 1 with no (or extremely little) training.  Number TWO - IT departments often don't have the time to train new recruits because they're already slammed as it is.  They're slammed because headcount is low.  Headcount is low because the C-level tends to think of everything in terms of ROI.  As I have said before and will say again, ROI applies to your IT about as much as ROI applies to your insurance policy on your home.

So the root of this problem goes right back to the very heart of the purpose for this blog, and my particular passion, which is communicating the challenges that business and IT face.  Drag the failures into the light, look them over really good, then use some common sense and do what can be done to move forward.  So how would I recommend that the industry moves forward from this?

First of all, a reputable group of InfoSec practitioners or a reputable industry leader should formalize entry-level requirements and expectations that can guide HR to understanding of the unique attributes for the InfoSec hiring process taking into account all the different roles.  Next, organizations need to institute proper internal training and educational policies and initiatives.  If they're not already doing this, they should be anyway.  Lastly, the InfoSec industry should put at least as much effort into reaching out to the next generation of practitioners as it does in trying to reach the current generation.  There are a ton of webinars, broadcasts, and good Lord, the CONS that seem to be popping up like whack-a-moles, but where are the hiring conventions?  Where are the informative videos about how to break into the field.  Where are the recommendations from the current rockstars about what traits make a great InfoSec practitioner?  Yet we hear how much this industry is starving for new blood while we are being turned away by the same people and it is very frustrating and off-putting.

If what I have written above seems to make sense to you, the seasoned InfoSec practitioner or C-level executive, then please realize that I have absolutely no practical experience in the fieldHowever, lack of experience doesn't mean that new recruits are not capable of critical thinking and bringing about good discussion.  I have nothing but a Bachelor's degree to my name, with no certs (which I feel are a money-making crock anyway) and no experience, but I can see what is happening and I can communicate these issues.  If I can do it, I have no doubt there are thousands of others who can as well, and they are wanting to get their dream jobs too, and contribute to this industry. 

InfoSec can't be just about the tech, or the constructs, or the policies.  It has to be about people, and people are being left out in the cold for no good reason.  This needs to change ASAP, but it will take the big players on the field to make the change, and not the rookie standing outside beating on the door.