Time For A New Security Model (?)

Earlier this week I received an email from Justin Somaini, former CISO of Yahoo! and Symantec.  If you haven't had the pleasure of talking with Justin and you get the opportunity, I urge you to do so.  He's a brilliant, rock-solid security professional and an all-around Good Human Being :)

Justin has just taken on the new role of Chief Trust Officer for box.com, a company that markets itself as offering secure cloud-based file sharing solutions for home and for business.  In his new role, Justin is starting a dialog with security professionals around the need for a new security model.  Justin's initial blog post lays out what I call the classic ROI versus Luddite argument that security professionals find themselves in regularly.  Specifically:  new cloud based technologies offer companies the ability (among other things) "to remove legacy tech debt and enable services in a faster development and release cycles" whereas security professionals are still trying to "extend our 'enterprise' to devices as they traverse the Internet."

Admittedly, I have some problems with this characterization.  While I agree conceptually with where (I think) Justin wishes to go, the presentation of the problem in the aforementioned fashion fails to spend time asking why security professionals operate in this fashion;  indeed, the lack of root cause analysis tends to perpetuate the myth that security professionals "just don't get it" and just don't want to get it.  For most of us, this couldn't be further from the truth.

Typically, introducing innovative technologies into an enterprise environment takes one of three forms from a security perspective:

1. The Afterthought Model.  The technology team has already made a buy decision and at the nth hour (or later) has brought the security team to the table.  The security team is now forced to try and fit the square peg technology into the round hole of security -- in many cases, in a way in which the technology was not designed to operate.  In the end, the security team must either (a) reject the technology and be blamed for lost ROI, or (b) jerry-rig an unsustainable solution which reduces the efficacy of both the technology and the security infrastructure.  A lose-lose proposition all around
2. The Risk Acceptance Model.  The security team informs the technology team that there is additional risk associated with the new technology.  While the risk is beyond normal parameters, the security team is perfectly willing to allow the technology withn the environment if the additional risk is acknowledged and accepted at an appropriate level within the organization.  In many organizations this dialogue perpetuates a weeks (months?) long kabuki dance as the technology team (a) questions the risk calculus; (b) tries to get the vendor to persuade you that your perception of risk and/or the new technology is incorrect; (c) the vendor struggles to demonstrate that it has appropriate security controls and processes to mitigate the risk; and/or (d) the company leadership asks the security team to "find a way" to implement the new technology without addition of any additional risk inthe environment.
3. The Standards & Options Model.  This is the model under which I prefer to operate.  The security team outlines a clear set of controls and standards that are clearly articulated and clearly defined for the levels of risk/criticality associated with the technology.  Included with those standards are securty architectural patterns which demonstrate the preferred (but not the only) method of meeting thse control requirements.  When a new technology is introducted, the criticality is assessed and a set of required security controls is layered onto the technical requirements.  The security architects work with the technology team and the vendor to ascertain how the technology meets these standards...only to find that, in many cases, security has not been appropriately layered into the technology.  In the rush to innovate, the technology company focused primarily on operations as opposed to security...and basic requirements cannot be met in any reasonable fashion.  

I admit freely that I am generalizing about technology vendors as well as  technology adoption models...but I think that most of us would agree that we have been in one of the three aforementioned buckets at some time in our security careers.  While this does not abrogate the need for security professionals to keep an open mind re: new technologies as well as to remain abreast of technological improvements which occur, it remains difficult (though not impossible) to embrace innovation and new technologies in an environment where ROI and technical debt reduction is not balanced against acceptance of risk  by the enterprise and/or innovative accomplishment of security objectives by the technology vendor out there.

Time for a new security model?  No.  The model for security has been and needs to remain the appropriate balancing of risk versus return within an organization.  Time for a new security implementation model?  Maybe.  If there is an alternative implementation schema that provides appropriate levels of trust; balances liability and risk; and achieves the appropriate level of accountability and efficacy re: security, then we should explore if not embrace such a model.  

If there is a vendor/technology out there that can assist in providing such solutions, we should definitely listen...but vendors and technologists need to understand their roles in this dance as well.  ROI without security is a flawed calculus.  Vendors who sell innovation without security are setting their customers up for failure and delaying (if not eliminating) adoption of their products.  I applaud Justin's call for a dialogue and discussion...but he needs to bring the other members of the vendor-security-technologist triad to the table if he intends to succeed.

My two cents...

Hacked Baby Monitor Caught Spying on 2 Year Old in Texas

Last week a couple in Texas awoke to hearing a stranger's voice in their two year old daughter's room.   What they found when they investigated was that a hacker had taken over their baby monitor and was using the monitor to communicate to the child.  Indeed, the parents watched the camera rotate to observe the parents when they walked in to unplug the unit.

The practice of taking over webcams in nothing new, but this story truly highlights the dangers of adding additional technical capabilities atop of an unsecure underlying network.  A great cautionary tale for your folks on a personal level...and a timely parable for your businesses re: the importance of fixing the security basics before adding capability/functionality.  

You can find the article here.  Worth your time...

8 "Terrifying" Cybercrimes of 2025

As I was catching up on my security reading this morning, the tagline of this techradar.com article caught my eye (as it was clearly intended to do).  

In truth, there is nothing earth-shattering postulated in this article;  indeed, those who regularly think about the intelligence and predictive portions of security have opined various scenarios like this for the past few years.  What's interesting, though, is to step back and realize that the technology and expertise needed to execute these scenarios exists today...and to consider how such scenarios could impact your own security environments even on a smaller scale.

Don't just read this as "pie in the sky" fear-mongering, folks;  rather, dissect these scenarios and think about similar concerns within your own environments.

A short but interesting read.  You can find the article here.  Enjoy!

Security fix MS13-061 breaks content index on Exchange Server 2013

To those of you waking up to problems with Exchange 2013 server, Microsoft has announced that a recent security fix (MS13-061) inadvertently breaks the content index.  Details re: fixing this problem may be found here.  Spread the word!

More Random Thoughts on Big Data Analytics

Earlier this week I was asked to comment once again on potential issues and concerns around big data.  This time, the concerns were around bad analytics being applied to big data.  In an article recently published on searchCIO.com, a benign example of bad analytics being applied to big data resulted in the funding of a research grant where no correllation of facts actually existed.  Other articles point to the potential for people being wrongly excluded from vital benefits such as healthcare or the government making egregiously bad decisions based upon poor analysis (as if that has never happened before :) ).  Below are some of my general thoughts on the topic your amusement:

1. Data and Information Are Not Synonymous Terms.  Data are facts;  information is a fact (or facts) in context. Removing context from data can obsure its meaning as effectively as encrypting it.  For an example, take the 10-digit number 3015553078.  Standing alone as datum, without context, this number has no meaning.  If we were to give it context by, say, adding commas (3,015,553,078) or by segmenting it in two (30155 53078) the data takes on some level of significance.  Only by adding the proper context, though -- in this case, (301) 555-3078 -- can we extract the proper meaning (or information) behind the datum provided.  
2. Intelliegence Requires Data and Information.    Intelligence is a collection of information which has political and/or military value.  By analyzing data and information we can accurately extract hidden information of significance and relevance.  In the above example, for instance, if you were given the information that (a) 301 is the area code for Maryland and (b) I used to live in Maryland, you might be able to conclude that the aforementioned telephone number used to be mine.
3. Big Data Collection Risks Removing Too Much Context.  This is especially the case with unstructured data.  In many cases the only context searched for is a cross referencing between an individual and certain terms.  The more those terms come up, the more an individual is assumed to meet a certain criteria.  For a real-world example, I harken back to the late 80's/early 90's.  Around this time, law enforcement officials in Dade County began stopping individuals traveling north on I-95 for suspicious of narcotrafficking.  Based upon their data, most overland drug couriers were (a)  dark-skinned males (b) between the ages of 20 and 30 (c) driving late model luxury cars who (d) made it a point not to speed.  Based upon this confluece of data, I was once pulled over for such a stop...despite being in military uniform with my West Point ring proudly on display.
4. Data Analytics Is A Starting Point, Not An End Point.  Using the example in (3) above, even I can understand why I was pulled over;  what continues to annoy me to this day about that situation is that the officer insisted upon doing a full search of the vehicle despite me offering both positive military ID and a set of valid military orders.  As I fit the selection criteria for a profile stop, the officer felt it reasonable to ignore all other information being presented and delay my journey north for over an hour.  This, to me, epitomizes the problem with big data analytics.  Even the best-written search strings and heuristic models will get it wrong.  While the best models can achieve as much as a 98% accuracy rate, a 2% error rate scattered of 1 million selectees still amounts to 10,000 erroneous results.  If these results pertained to, say, healthcare coverage, the impact could be tremendous.

My bottom line with big data analytics is this:  utilizing the data to narrow the pool through which a human being must search may (note word) be sensible and proper depending upon the context.  Utilizing a data search query for ultimate decisioning without human intervention is short sighted and will lead to potentially life-changing errors.  As pundits who advocate big data continue to extol the potential efficiency gains of the associated technologies, we as security professionals must ensure that we do not lose sight of the dangers associated with its irresponsible use.

My two cents...

Yet Another Twist to Credit Card Phishing

(The following is reposted from www.securityweek.com.  You can read the original posting here.) 

According to Daniel Cid, Chief Technology Officer at Sucuri, phishers are breaking into e-commerce web sites and surreptitiously planting code to redirect sensitive payment details to third-party domains.

"The attackers modify the flow of the payment process so that instead of just processing the card, they redirect all payment details to a domain they own so they can steal the card details," Cid explained in a blog post.

The trick involves very stealthy, minimal changes to the hacked site. This is done to ensure persistence and to stay undetected for as long as possible. 

In one example, Cid showed how a credit card processing file on a hacked e-commerce site was modified to either transmit the credit card data via e-mail or redirect the data flow to a new domain.

The third-party domain receiving the stolen data looks almost like the payment handling site (slightly misspelled to avoid detection). 

"This redirection forces all the transaction data, including credit card details (name, address, CC and CVV), through their malicious server, in turn allowing the data to be stolen by the bad guys," Cid explained.

Interestingly, the data redirection does not affect the actual credit card transaction. Instead, the phishers are basically siphoning all the confidential data during the transaction process, quietly stealing credit card data without triggering alarm bells.

Infographic: Insuring Against a Data Disaster

Experian and the Ponemon Institute have released a new white paper which discusses the current state of cyber risk insurance.  Nothing earth-shattering in their findings, but it's a good refresher/primer on the insurance options that exist and should be taken into consideration.  You can find an infographic which summarizes some of the salient points at this link.  Note that you will need to provide your contact data to Experian to get ahold of full white paper. Enjoy!