By now, you’re probably well aware of the fate recently befallen on the Brian Krebs site KrebsOnSecurity.com.  A Distributed Denial of Service (DDoS) attack in excess of 620/Gbps caused such a strain on one of the world’s largest DDoS protection services, that Krebs asked that his site fundamentally be black-holed until the storm passed.

What you may not have heard of is yet another attack a few days later on OVH hosting, which demonstrated a similar type of attack that reached almost 1/Tbps – almost a 50% increase over that which took the Krebs site offline. OVH also reported that over 145,000 devices were involved in the attack (https://www.hackread.com/ovh-hosting-suffers-1tbps-ddos-attack/).

What do these two attacks have in common?  Yep – you guessed it – your refrigerator. No, wait, your television.  Oh, I’m sorry, I meant your thermostat. My mistake, it was your pacemaker – oh, and don’t worry, you weren’t having palpitations the other night, it was your heart launching a DDoS.

Ok, so perhaps a bit tongue-in-cheek, but the reality is, there are millions of devices on the Internet these days, the so-called Internet Of Things (IoT). While I don’t argue that it’s wonderfully beneficial to have my fridge continually remind me about picking up eggs, I have to admit, even as a self-proclaimed geek, I have never patched my fridge’s operating system.

(I’ll pause here momentarily to await the punishment of the InfoSec Gods)

In all seriousness, as I sit here at zero-dark-thirty, with nothing but the rainbow colored LED’s of the multitude of electronics lighting the room, I have literally counted dozens of internet-connected devices that are in no doubt in need of a firmware upgrade.

Yes. Dozens – and that’s just in the ‘typical household appliances’ category such as WiFi routers, TV’s, DVD/BR players, DVR’s, surround sound systems, security systems, and gaming consoles.

So, if a guy who eats, sleeps, and breathes InfoSec can’t keep up with ensuring his home devices are patched, how the hell do we expect the average consumer, who can barely keep their actual computer’s OS up to date, manage to?

I can see the dialogue now:

Husband: Honey, I need to push a firmware update to the fridge.

Wife: Wait – didn’t we have to buy a new one the last time you did that?

Husband: Yeah – but I’m sure I got the right version this time. I just assumed

we were running a 64-bit OS before. I won’t make that mistake again.

Wife: You know what happens when you… Assume.

Husband: …..

While the DDoS attack that impacted OVH was mainly cameras and DVRs just hung out on the net, it truly makes you wonder about the design considerations of *any* internet-connected tchotchke that could possibly be weaponized for further attacks. Who – and as importantly, how – are we going to patch the millions of devices already on the Internet and keep up with the thousands that come online every day?

We are already so far behind the curve that it may just be impossible to ever catch up. Perhaps the Army of Things is not just already deployed, but fully weaponized and ready for battle.

Consider this in the parlance of the real-world military.  In the Army, a Lieutenant General oversees about 75,000 troops whereas a General has about 150,000-200,000 troops under their command. OVH is claiming that they could identify in excess of 145,000 devices – aka troops – attacking them at one point.  Based on troop numbers alone, that puts the attackers on par with some of our best Generals

The reality is that most botnets are substantially larger. For example, the Necurs botnet alone is estimated to have about 1.7 million devices under its control, compared to the entirety of the US Military’s 1.3 million troops (DoD Budget proposal, Feb/2016).

How’s that for perspective?

So, besides the obvious DDoS threat we’re all facing, how does this relate to the average enterprise CISO? It’s actually quite simple – it’s all about the design.

If you think about it, none of these devices were *designed* to be patched by the average consumer. The design was hyper focused around functionally and speed-to-market, with no thought put into the operational impact it would have. We’ve recently seen malware specifically targeting Java-based televisions, but yet, how is the consumer to know that the fancy ultra high def 4K resolution 65-inch screen sitting in their living room has been infected with a root kit that allows an attacker to turn on the camera remotely? When the manufacturer was designing this, did anyone stop and say, “Hey – we should automate patching so the consumer doesn’t need to worry?” I’m betting the answer is no.

But yet, time after time, breaches are a direct result of design issues and far less about the uber hacking skills of an attacker. Make no mistake about it; while we certainly face our fair share of creative and skilled attacks, it’s the SQL injection attack, or the mismanagement of sessions, or the lack of multi-tier defenses that makes a great breach.  All of which are design considerations.

While I’m not sure of how we will ever fix the Army of Things problem, besides perhaps, developing some proactive, polymorphic shellcode, we certainly should learn from the disastrous situation we now have on our hands. How do you handle the design decisions in your enterprise? Are you involved from the budget cycle onward? How about from project kickoff?  Does your team participate in any application development sessions? Do they meet with the intended user? Have you considered the long-term operational impact of the decisions you’re making? How difficult is it to patch?

Obviously, many more questions can be asked, but hopefully these few items will help you get in front of your application and infrastructure teams and avoid any disastrous design decisions.

The post The Army of Things appeared first on Security Current.

Consider for a moment the business lines that drive your company’s revenue. If the president of that business unit had an 85% assurance that a new business venture would be successful, would they pursue it? Likely they would.

Neil Armstrong, one of America’s greatest heroes, once commented that they had a 90% chance of returning safely to Earth but only a 50% chance of pulling off a successful Apollo-11 lunar landing – but yet we still went and achieved one of mankind’s greatest missions.

So, if the experts on the Apollo team felt there was only a 50% chance of a successful lunar landing, and yet, we still accomplished this amazing feat, why wouldn’t you leverage a security control that, by all accounts, has a 100% chance of an 85% reduction in attack surface?

Lets face it – although many of us despise using F.U.D. to drive our programs, we do rely heavily on statistics and probability (and gut instinct) to drive our risk decisions. We evaluate the complexity of the attack, the susceptibility of our individual infrastructures to the threat, and finally, the level of effort and time required to mitigate the risk. And while we make these critical decisions virtually every day, far too many choose to turn a blind eye to the 800-pound gorilla lurking in our enterprises.

Local Admin Rights.

There… I said it. Publicly. Not in the back alley of the latest InfoSec conference; not in a hushed whisper to trusted colleagues; not over some secret encrypted covert channel.

No – It’s time that we collectively fix this problem. And yes – I completely understand the gravity and impact of what I am saying.

Lets face it, giving the average end user Local Admin Rights to their corporate PC or laptop is tantamount to giving the babysitter the keys to the liquor cabinet – nothing good can ever come from it.

According to a recent analyst’s report, we spend billions of dollars each year, about $75 billion in 2016, throwing technical solutions at people problems, and yet not a day passes without another breach making headlines. Sure, there are fundamental solutions we need to have in place to secure and monitor our infrastructures, but after that, what tools are really going to fix our problems? We will always have users who click on email phishing links, or malicious ads being delivered through well-known sites, and malware-laden open source delivered by trusted partners.

The reality is that any CISO who’s been in the seat for more than a few weeks knows, in their gut, that the Local Admin Rights issue is one of the biggest risks we face, and concurrently, one of the most intimidating to address. User revolt, executive outrage, and inundation of the help desk are just a few by-products one can expect when tackling this topic in the corporate enterprise.

But I ask you this – How long until that breach occurs? How long before you’re standing in front of your board of directors trying to explain why you need to buy some cryptocurrency to payoff an unknown figure to decrypt your files? How long until you’re the headlines in tomorrow’s news?

Tell me – How long until you step up and fix the single biggest exposure in your company?

Remember, this is the Anti-FUD zone, so before you answer, perhaps a little research project is in order. Before you pass this off as a CISO’s bucket-list dream accomplishment, do this one thing for me. Go back over all of your incident reports for the last 12 to 18 months and see how many of them would have been mitigated – even to a small degree – if the user had not had Local Admin Rights. Would the malware have even installed? Would the malicious actor have been able to bounce from host to host almost invisibly? Would they have been able to open a command shell and scoop packets off the wire? Seriously – don’t take my word for it. Use your own empirical evidence to provide the foundation for the argument.

All this being said, I readily admit this is likely to be one of the biggest challenges any CISO will face, but I also firmly believe that it’s one that will make the biggest impact. I also believe that we are beginning to see a ‘return to center’ when it comes to what employees are allowed to do on their corporate workstations and the acceptable risk that accompanies it. After all, if we don’t control the endpoint, someone else will.

If you decide to undertake such a mission, here are a few approaches you may want to consider. Most are self-evident, but worth highlighting.

●Start small: Pick strategic groups and test on a small subset of your user base. Get buy-in from the teams and engage them early and often. This is an effort that needs to be done in partnership with your IT support and help desk teams – not in spite of them.

●Eat your own food: Make the InfoSec team a model example of what’s possible. You control your own destiny – have your team lead the way by giving up their admin rights and prove to everyone else that it’s possible.

●Leverage the deployment of a new OS: Many are, or soon will be, considering a full Windows upgrade. Why not leverage that deployment as an opportunity to lock down the user rights?

●Consider alternate accounts: Do you have some power users that you don’t want to pull the rug out from under them? Why not provide them with a special account to ‘Run As’ that will give them the occasional elevated privileges when needed? This also will enable you to monitor those accounts and follow up with the users as to why they needed to elevate privileges in the first place.

●Be cost conscience: While you could deploy a solution to address some of the potential process changes from removing a Local User Admin, there isn’t a requirement to do so. Yes, there will likely be an FTE expense to get the work done and possibly an uptick of a headcount or two at the help desk, but you do not need to drop seven figures on an Identity and Access Management solution (IAM) to solve this problem.

In the event you need context and metrics around the overall risk that a Local User Admin introduces, you’ll be able to find a few data points in these reports:

●Verizon 2015 Data Breach Investigations Report

●Avecto 2015 Microsoft Vulnerabilities Report

●Balabit Top 10 US/UK Hacks 

Finally, in keeping with the Apollo Mission theme…

[We choose to rid ourselves of Local Admin Rights]… not because it is easy, but because it is hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win.

The post The Best Security Control You Never Use appeared first on Security Current.

In this two-part Q&A, Morey Haber and John Masserini discuss the current and future state of biometrics. Industry thought leaders, Haber and Masserini address leading questions surrounding biometrics from the vendor and enterprise perspective.

In part one, Morey and John examined the possibility of biometrics as a replacement for existing authentication technology and discussed methods for using biometrics to augment existing solutions.

In this installment, Haber and Masserini continue their assessment of biometrics and other forms of adaptive authentication. They also examine the process for retaining and purging biometric data, and draw conclusions.

Q: What forms of biometrics are you considering? Fingerprints, facial recognition, infrared, retina, voice, behavioral, etc.?

Haber: While I have been focusing on fingerprints for this discussion, many other techniques exist for biometrics that can be successfully integrated into your security model. With any of them, all the considerations above must be considered and altered accordingly.

For example, if you plan to use a retina scanning device, rotation of the biometric data makes absolutely no sense. If you plan to use the facial recognition in Windows 10, the security of the hardware needs to be considered as well since you are potentially using a very pricey piece of camera equipment to perform infrared and visual identification.

Personally, I think fingerprints will be the primary deployment vehicle for most organizations, followed by esoteric techniques based on behavior (like keystroke monitoring of a password based on time and pressure) to augment current security mechanisms.

Masserini: Most biometric alternatives are too costly to implement on a wide scale, so fingerprints remain the choice de jure for general adoption. Facial or retina will likely only be used in selective, highly secure areas. I think 2016 will see a huge jump in the adoption of behavioral analytics to augment the existing enterprise controls.

Over the past eighteen months, we’ve seen a significant uptick in solutions which perform User Behavior Analytics (UBA) monitoring which can enhance the monitoring and alerting aspects of the existing security infrastructure. As these products mature and the models hit a consistently reasonable level of accuracy, we will likely be able to leverage their decision capabilities by incorporating them into the authentication process.

Imagine how seamless an authentication process would be if we were able to model a user’s behavior and immediately determine if we need additional credentials before allowing them to perform a specific function.

Q: What other adaptive authentication technologies could benefit from biometrics? Two Factor?

Haber: Biometrics can successfully augment almost any existing security mechanism if it is implemented with solid ergonomics, and physical security and encryption in mind. For example, having a fingerprint reader on a two-factor key fob sounds like an effective way to retrieve a key, if battery life and local biometric data is properly secured on the fob.

While mobile applications can replace this hardware (in lieu of a fob), the concept of tying multiple identification techniques together with dissimilar data types just makes the process of authentication more secure.

So consider how you add biometrics. An external USB biometric reader may sound attractive to add for access, but its simple theft can easily be used to retrieve a user’s fingerprint. Ergonomics and physical (above battery life) need to be considered when merging with existing solutions.

Masserini: Many of the newer biometric solutions allow for multiple templates to be created for each user, providing certain ‘randomness’ to the authentication process. Although admittedly a bit scary, imagine if we had ten legitimate passwords for each user ID.

We could use any of the passwords to login, but could never use the same one back-to-back, or perhaps the same one on any given day. While unwieldy with a username/password combination, it’s a perfectly feasible solution with fingerprint biometrics.

Another option is the use of multiple fingerprints (or biometrics) for basic authentication, providing an arguably strong form of identification. Models such as these not only make the user’s life simpler, but add a control not available in today’s password-centric world.

Q: Any additional thoughts?

Haber: For biometrics to succeed there will always be a need to add additional elements to verify a user’s identity. The more you can separate biometrics from a documentable authentication scheme, the more secure the system will be.

For example, take this concept, which I have yet to see implemented, called a Biometric Pin. The method uses a traditional secure fingerprint biometric reader, but has logic to require more than one fingerprint. A user selects 4 fingers to scan from both hands just like applying a pin. They then register them in their mentally defined order. I.e. Left Thumb, Right Middle, Left Middle, and Right Index.

The technique requires all four biometrics in the proper order (analogous to a pin) and only storage of these four fingers. The sequence of fingers, and which finger, is not known to the system and policy requires a new rotation every “n” days. In this scenario, biometrics alone could be used for authentication or authorization since it incorporates more elements than a single fingerprint and requires mental (difficult to document) knowledge of which fingers to apply and in which order.

While this suggestion is just a hypothetical example of how to implement secure biometrics, it illustrates that any single biometric technique alone will never be sufficient.

Masserini: While biometric solutions have a solid place in the enterprise, it’s more augmentative then disruptive. While we are still far from the replacement of passwords with biometrics, advancements in the biometric space will continue to challenge us to re-think how could better utilize such an approach.

I truly believe that Behavior Analytics will be a driving force in the next 24-36 months and will mature to a point where we can integrate their models into Adaptive Authentication solutions to truly make automated, intelligent decisions about needing additional credentials based on activity or action rather than the specific username.

I also believe that a well thought out implementation of biometrics stands to mitigate the weakness we currently face with passwords, albeit not by replacing them, but by giving us alternative means to verify users without overburdening them with additional passwords or tokens.

The post Point/Counterpoint: The Current State and Future of Biometrics – Part Two appeared first on Security Current.

In this two-part Q&A, Morey Haber and John Masserini discuss the current and future state of biometrics. Industry thought leaders, Haber and Masserini address leading questions surrounding biometrics from the vendor and enterprise perspective.

Q: Can biometrics replace any existing authentication technology today?

Haber: Yes, but there is a lot of work, and additional security, that is needed for biometrics to be a secure and viable solution. For example, biometrics should only be used for authentication or authorization but never both at the same time.

In addition, biometrics alone, without a pin or other verification media is insufficient. Furthermore, technologies need to evolve to ensure that a fingerprint alone cannot jeopardize the integrity of the system. Plus, security policies for storage, encryption, and even biometric rotation (like password rotation) need to be clearly defined and successfully implemented and enforced.

Masserini: The biometric industry has certainly matured over the past decade, providing several trustworthy solutions, but I’d rather say it’s a part of the maturation of authentication technology rather than a replacement of it. Most biometric solutions require a pin when used for authentication, and in reality, a pin is no more or less secure than a password.

The biggest challenges of biometric deployment are the delineation between authentication and authorization. Today’s authentication technologies combine both of these factors into a single action, rather than a deterministic view of identification versus action.

While it is feasible to deploy a biometric solution in the same manner, one must question why you would go through the effort and expense to only nominally increase security. By leveraging existing authentication technology along with a biometric solution, you can significantly enhance the control, while simultaneously making it easier for the user.

Q: When should biometrics augment existing solutions?

Haber: Consider any security model that it is easy to document or communicate. The authentication mechanisms for these security models are via paper, verbally, electronically, or even a text message. A username and password is a traditional example of this. Both strings are easy to document.

Biometrics is a great addition to this type of technology, or even using PIN codes, to ensure the proper identity is using this less secure authentication vehicle.

Masserini: I think a key point that needs to be made here is ‘authentication, not authorization.’ There are a number of easily adaptable solutions on the market that can leverage biometric authentication within the enterprise. The challenge comes when organizations who have typically taken an ‘all data is equally important’ position try to delineate between various access rights.

Let’s face it, when most people think about biometrics, they think it is just an ‘easy PC login,’ which is basically only moderately better than where we are now with passwords. To fully appreciate what a biometric solution can offer, organizations should separate the authentication process from the authorization process.

For instance, I may grant a device access to a network based on a biometric authentication, but lock them into a network or limit the devices capability until further authorization credentials are supplied – basically adaptive authentication. Now you need to get on the web? Perhaps the fingerprint is enough. Now you want to send an email? That requires a pin as well so I know you’re authorized to do so.

Biometrics can offer a great deal in enhancing the controls in the infrastructure, but only if deployed thoughtfully – otherwise, it’s fundamentally nothing more than a username/password control.

Q: When should biometrics never be used?

Haber: Biometrics should never be used alone for access regardless of authentication or authorization. Door locks are a perfect example of this problem. A stolen fingerprint can easily be manufactured to bypass the physical security of the device and compromise the contents behind the door. A second example is your mobile device.

A fingerprint is used for authorization and authentication in the case or logging in potentially access a financial mobile app pay. While this is not as risky as a biometric door look, since it assumes you have possession of the device, it represents and unacceptable risk for entities securing more information than just a consumer’s device, personal financials and information.

I would never allow an application on a mobile device that uses its local biometric system alone to ask sensitive data within an organization. There should always a second mechanism on top of that to provide the users identity.

Masserini: That’s basically asking ‘when should a password never be used.’ Biometrics and passwords are becoming fairly ubiquitous so it’s more of a question around what the risk is.

As stated several times already, one should never rely solely on a biometric alone as a method of strong authentication, but as a key part of a multi-faceted, multi-tier authentication architecture. For example, presuming the fingerprint reader on a mobile device is trustworthy, then sending that same device an SMS code for logging into a critical service doesn’t not provide the level of assurance required to say, process a six-figure wire transfer, however, it may be good enough to check email.
Upcoming Part Two:
In the next installment, Haber and Masserini continue their assessment of biometrics and other forms of adaptive authentication. They also examine the process for retaining and purging biometric data, and draw conclusions.

The post Point/Counterpoint: The Current State and Future of Biometrics – Part One appeared first on Security Current.

Look, let’s be frank – the week of the RSA Conference is a scheduling nightmare. On easy days it takes effort to manage, and on difficult days it’s completely unwieldy.

There are more sessions, activities, keynotes, networking events and ancillary get-togethers than you can possibly imagine, both in and around the actual conference. With the exception of the actual RSA training sessions, being double and triple booked is commonplace.

I look at RSA Conference with mixed emotions. Years ago, as a consultant and technical contributor, this event was where I went to learn about new techniques and strategies, and geek-out over the crypto illuminati. I truly went there to be educated.

Now, as a CISO, the RSA Conference offers a different kind of education, but one you must develop a strategy for, otherwise, it could be a colossal waste of time. Over the years, I’ve managed to find some things that work, realized some things didn’t, and basically have figured out how to get the most from the event and all the interstitial happenings. Hopefully, you’ll find something valuable out of the list below, but as always, your mileage may vary.

The official RSA Conference:

This is the main reason we’re all in San Francisco – right? In one fell swoop, you can earn the vast majority of your CPEs for the year, gain an understanding into new approaches used by your peers, or go all uber-nerd and hear what the cryptology elite are worried about in the coming year.

The truth is, most CISO’s don’t need to know about the next generation of prime number sieves (although we may want to) or side channel attacks; we need to understand how the next evolution of crypto – or APT detection – or micro-virtualization will impact our enterprises.

Many of us grew up on the technology side and evolved into our current pseudo-tech / pseudo-business roles. However, the RSA Conference can make you feel like Michael Corleone himself, uttering those immortal words, “Just when I thought I was out, they pull me back in.”

If you are an exceptionally hands-on CISO, then perhaps you should pepper your schedule with a few technical sessions, but for the most part, tracks like C-Suite View, Governance, Risk & Compliance, and Security Strategy are great values for a new CISO or one in a new organization who is looking for a refresher.

The RSA Expo floor:

1000100100. That’s the magic number this year. No, it’s not over a billion booths at RSA (although it really does seem like it), but 548 vendors split between the North and South Expo centers. The Expo is open for 21 hours – 1,260 minutes in total.  That means, even if you did nothing else at RSA except visit the Expo, you would end up spending 2.5 minutes per vendor.

Ridiculous, right? So, with a limited checkbook and unlimited expectations, what’s a poor CISO to do?

Likely, we can all recite both our 12-month tactical and 3-year strategic plans in our sleep. We know what we need to address in the coming year and how that plays into our long-term program maturity goals. The RSA Expo is a great place to sniff out future partners. From product solutions to consulting firms to awareness tools, the Expo floor can provide you with a list of items to consider. That said, you must be strategic on how to approach such an expanse of floor space.

You have two options really, one is amazingly simple, the other tedious, but old-school effective. If you haven’t done so, download the RSA Conference app before you read another word. Once you setup your account using the same credentials you registered for the conference with, you can search the exhibitors for the ones you want to visit and add them to your personal list.

Once added, you can see them under ‘My Exhibitors’ on the app’s main screen. Just select the vendor you want to visit, tap the pin in the upper right hand corner, and whala!, the booth is highlighted on the expo floor map. By the way – side benefit – the app can manage your entire session schedule as well. You’re Welcome.

Now, while I’ll begrudgingly admit that I used the old-school method for more than one conference, I’m thrilled to retire the printed-expo-map-multicolored-highlighter solution that was all the rage years ago. However, if you’re in the mood to go all-out retro, you can go over to the  Expo and Sponsors page, download the PDF for each floor and highlight away.

Private Vendor Suites:

Over the past several years, private vendor suites have become hugely popular during the conference. Many vendors now get a suite at one of the area hotels for private, one-on-one, demos and meetings. The ability to have a normal conversation, without the worry of someone overhearing, interjecting, or diverting the discussion is actually quite refreshing.

Most of the suites are less than a couple minutes’ walk from Moscone and are fully outfitted with the vendor’s entire catalog offering, allowing you to get hands-on with their products. The suites are usually staffed by their best folks, who can answer any questions you have and can actually show you the wheres-and-hows right on the screen.

The only caveat is that these sessions usually need to be scheduled beforehand. Don’t walk up to a vendor on the exhibit floor and expect to get an invite up to the suite – it’s highly probable that all the slots are booked by that time. If you have a particular interest in a vendor, reach out to them now and ask for a demo. Most will happily make the time for you.

Planned Networking Events:

There are several organizations who manage networking events around the conference, in some cases even the weekends before and after. Most, if not all, of these events are sponsored by vendors who have their executive management on hand to answer questions, discuss road maps, or offer customer panels.

These events – which are usually luncheons, dinners and receptions – also double as strong networking opportunities. Many sell out in advance of the conference, but if you are looking for exemplary CISO-level networking, these are hard to beat. Since these are typically sponsored events, there is generally no cost to attend, but there is a pre-qualification process. All of these events are held locally, so they’re fairly easy to get to should you manage to snag an invite.

Ad-hoc Networking:

There’s something to be said for just kibitzing with your peers. In fact, one could argue that you’ll get more insight into a vendor, product, or program technique by talking to your peers than by spending time hearing the vendor’s pitch.

The relationships you will develop during the networking events or even just in the hotel lobby will be invaluable in the future. InfoSec is a strange bird that crosses competitive and geographical boundaries with ease, almost relying on the ability to pick up the phone and talk with a fellow CISO from someone else in your industry.

We are all facing the same challenges, so understanding what worked – and what failed – for someone else is invaluable knowledge. It’s critical that you avoid locking yourself away in the room for the four days during the event. Meet – mingle – exchange QR codes – do whatever it takes to meet your peers; it will make the entire RSA Conference experience infinitely better.

So there you have it. Enjoy your time at this year’s RSA Conference and let me know if you have any suggestions of your own.

The post A CISO’s Guide to RSA Conference 2016 appeared first on Security Current.

During a bit of down time this holiday season, I had an opportunity to catch up on a lot of my fellow security pundits’ predictions for 2016. Not surprisingly, there were countless predictions of major breaches, new ransomware threats and continuing cyber-militia activities.

In fact, depending on who you believe, the next 12 months will be filled with catastrophic infrastructure failures, massive financial breaches or the disclosure of millions of health care records… Who would’ve guessed?

One thing I noticed in many of these pieces is very few offered ways to prepare for such calamities. So, rather than trying to predict the sequel to the next Die Hard flick, I figured I’d share some practices and approaches that may help the average security executive weather the impending Cybergeddon of 2016.

In the words of the immortal Sun Tsu:

“The art of war teaches us to rely not on the likelihood of the enemy’s not coming, but on our own readiness to receive him; not on the chance of his not attacking, but rather on the fact that we have made our position unassailable.”

In the spirit of Tsu, I offer some topics to consider when developing your 2016 strategy.

Private Threat Intelligence ‘communities’ will become more prevalent

There is little doubt that one of the top practices in 2015 was the adoption of threat intelligence. Incorporating real-time data points and attack signatures into your ever-evolving security infrastructure has been a boon to early adopters. It will continue to play out as the technology and practices are refined and adopted by the more mainstream organizations.

But while the traditional security organizations begin to invest in the threat intelligence space, in 2016, those early adopters will begin moving towards shared threat intelligence communities – groups of like-minded organizations who share some specific risk or threat posture who will begin sharing far more specific information amongst themselves.

While participation in these communities doesn’t necessarily preclude them from sharing key data points with the broader groups, it will allow a far higher level of reliance out of the gate.

While the various ISAC’s provide this service to many in the critical infrastructure fields, there is still a need for finer levels of trust and control among peer organizations. Smaller, hyper-focused communities will begin to form between trusted organizations to share relevant threat indicators and provide for a trusted information sharing platform.

Cloud access security brokers gain strong adoption

Long gone are the days of trying to say ‘no’ to cloud services in the enterprise. That said, it is typically the security team’s responsibility to figure out how to integrate such services into the overall IT catalog of the dynamic enterprise – after all, who doesn’t want cheaper and more flexible infrastructure?

Cloud access security brokers (CASB) offer a solid control point (think: modern day proxy) by which the security team can provide authentication, authorization, encryption, and monitoring to many of the top cloud providers and services. A CASB solution can be either on-premises, or ironically, cloud based, and typically integrates with the directory services you already have in place.

Depending on the specific needs of the enterprise, either a forward proxy or a reverse proxy model can be introduced, each having their own pros and cons. Many of the solutions now offer integration with various security controls (i.e. activity logs), which allow your operations team to integrate the CASB into the security ecosystem as well.

In fact, over the past year or so, most of these offerings have matured into solid choices for enterprises of all sizes, and by all accounts, 2016 should bring a serious ramp up in the adoption and deployment of CASB solutions.

User behavior analytics will move from cool tool to integrated intelligence

If I was able to, I’d put user behavior analytics (UBA) up for the ‘Breakout Performance of the Year’ award. Many of the top players in the space not only won some serious deals this year, but they also garnered the attention of many a VC firm.

UBA solves a problem that we all have been dealing with for as long as the IT industry has been around: how do we discern the activity of a normal user from that of an adversary using a compromised credential? It sounds simple, that is, until you try to write a Hadoop query for it.

The reality is, any time you involve pesky humans, nothing is really straight-line predicable. It’s all about watching, modeling, comparing to like users, modeling some more, and feeding that back into the model, only to start all over again for weeks and months on end.

Many of the current UBA vendors have gone to extensive lengths to develop models and machine-learning algorithms to prototype a user’s behavior and compare that baseline to future activities. While this sounds like something directly out of Ex Machina, the evolution of big data technology coupled with some serious Data Science is actually showing promise.

Finally, in contrast to some of the mistakes that early threat intelligence vendors made, many of the UBA vendors have focused on integration capabilities as well, allowing you to keep your single-pane-of-glass while still taking advantage of the algorithmics of the solution. This integration approach will provide long term intelligence into the entire ecosystem, enhancing all aspects of the control base.

And since I haven’t gone out on the ledge too far already, how about a few bleeding-edge considerations that will likely start gaining traction throughout 2016…

• Blockchains in the workplace: While most only consider the use of blockchains as a fundamental necessity in the cryptocurrency space, the technology and practices behind them are getting a serious look from the financial industry. Insurance companies, investment firms, and mortgage companies are taking a hard look at implementing blockchain technology as an effort to revamp their back office processes. These early adopters are driving the adoption of some fundamental practices that will likely take off in 2017.
• Fixing the User… Credential: It’s simple – everyone’s tired of the user ID & password – and none more so than security execs. We need to get rid of the antiquated method of user identification once and for all. With the continued adoption of Radio-frequency Identification (RFID) and Near Field Communications (NFC), along with the implementation of the fingerprint readers in portable consumer devices, we now have a way to have a fairly high level of confidence that the person logging in is who they say they are.

  While admittedly it’s not perfect, there is a valid argument around it being good enough for financial transactions, then why can’t it be good enough to check email? Several large and small companies are working on great solutions that also implement a solid Adaptive Authentication process as well. With any luck, 2016 will see wider adoption of this type of solution with a few fairly big names announcing product suites. This is really something to watch for, because we all know that people would turn around and drive home for their phones, but feel perfectly fine without a purse or wallet.

• Micro-perimeterization becomes a strategy: Yes, Virginia, there is still a perimeter. Sort of. We’ve all heard ‘The End Of The Perimeter’ death march for years now, while there is some justification to it, I believe it’s far more likely to just shrink rather than die. While ‘The Cloud’ has been a transformative approach to providing infrastructure services, security teams have struggled with how to secure and protect the businesses – many times in spite of themselves.

  That said, we are now seeing an evolution in leveraging solutions that not only use the cloud model, but do so in a way that traditional security approaches failed at. The concept behind micro-perimeterization is leveraging pre-staged virtual machines for various services that automatically include all of the necessary security controls built in. Need a web server? No problem – here’s a VM with all of the apps you need, firewall/IPS preconfigured, and connectivity to the SIEM already in place. No need to put this behind the legacy corporate firewall since it already has all of the controls built in. Oh – and a side benefit? No unnecessary intra-perimeter communication, so even if one of the services goes down to an attack, it can’t impact the other services, much like what would happen in a typical enterprise DMZ. Yes security pundits, in 2016, the cloud is our friend… finally.

So there you have it, my take on what 2016 may hold for better or worse. I can’t wait to see what pans out.

The post Three Things to Consider in 2016 appeared first on Security Current.

Sometime ago, I had a moment of introspection, which oddly, sounded a lot like Redd Foxx, in his best deadpan Fred Sanford delivery…. ‘It’s the user…. Dummy!’

Those of us who have been in the space for a while recognize the one common factor in every significant breach is the abuse of privileged accounts throughout the kill chain.

Whether it’s a local windows admin account used to install the malware, or truly owning a server’s root account allowing the attacker full access, privileged accounts are critical for a successful breach to occur.

Holistically, as an industry, we have continually moved from the outside in. Decades ago, we focused on the external networks, protecting the soft inside with a hard exterior shell.

Over time, that focus moved to the internal networks, then the application layer, and then to the storage layer, always chasing the attack vector or exfiltration method rather than focusing on the kill chain. At the end of the day however, without user credentials, the attackers life is immeasurably more agonizing.

While gaining access to privileged user credentials is one of an attacker’s primary objectives, identifying the difference between normal user behavior and suspect activities has always presented a unique challenge in security analytics.

By definition, admins are often expected to be able to ‘go anywhere – do anything’ in order to be able to, with a few deft keystrokes, get the production system back online or install that piece of code that is critical for the business. Admins are the key to a successful operations environment.

So how, from a monitoring or predictive analytics perspective, is InfoSec supposed to monitor the use of such accounts without being the reason the production system was down for an extra five minutes?

I think the time has finally come.

Over the past 12 months, an interesting congruence has occurred between two distinct solution sets – the operational controls of the stalwart Privileged Access Management (PAM) and the bleeding edge algorithmic modeling of User Behavior Analytics (UBA).

PAM is the management and control of user accounts which have elevated or privileged access to various systems. Typically, these are perceived to only be ‘root’ or ‘Administrator’ accounts, but in reality, these are any accounts that have the ability to change a configuration, install/delete software, or provide access to information that they would otherwise be precluded from accessing.

Although historically, PAM was a ‘we offer that too’ solution proffered by a number of vendors, recently it has become a major focus for organizations due to the realizations that many of the publicized breaches over the past 18-24 months have had some aspect of privileged account abuse as part of the attack.

UBA is the algorithmic modeling of user behavior over a given time period and comparing of that behavior to future activities in the hopes of identifying miscreant activity.

Unlike a typical Security Event/Incident Monitoring solution, which focuses on the aggregation and correlation of events, UBA products continually re-evaluate current and historical events recursively, improving the future state of the model.

The theory behind UBA is that when the attackers obtain access to an infrastructure, the first thing they go after is the privileged accounts in order to ensure their long-term presence in the systems. By abusing such credentials, they can install rootkits, hidden malware, and any other suite of tools they may need to ensure they get – and keep – system access.

By comparing the original ‘clean’ user model to future activities performed by the account, deviations can be used as indicators for the security team. While the UBA space is somewhat nascent, there has been a tremendous amount of effort put into developing some fairly complex algorithmic models to address the inconsistencies of the various enterprise environments.

In fact, the UBA space is expected to have a compound annual growth rate of 100% over the next few years, going from $50 million to over $200 million by 2017.

Most industry experts argue that a breach is unavoidable and we need to focus on rapid detection and limiting the extent of the breach. Given that, how can we leverage the salt-and-pepper haired maturity of a PAM solution with the hot and sexy techno of UBA to provide our teams with rapid detection and protection of our critical assets? Is it even possible to model user behavior if there is a lack of trust of the environment they are working in? Can an existing, legacy infrastructure adequately model user behavior to a granular enough level that the information is useful to the InfoSec team?

I believe we can, and in fact, we must.

The entire concept of managing privileged access treads into the forbidden woods of most IT organizations.  When a PAM solution is introduced, likely the very first question is “Why?, don’t you trust the admins?”

The reality is it has nothing to do with the admin, either personally or professionally. It does however, have everything to do with their system credentials. We have to get beyond the trust discussion and really have an open dialog about risk – the risk they take surfing the web, opening up the email from the unknown sender, or installing that app downloaded from who-knows-where.

To be honest, I completely trust the admins I work with every day, but that doesn’t change the fact that we have built an in-depth control structure around their access. That said, they also understand that their god-like superpowers in our environment make them a legitimate target for the bad guys, and frankly, the last thing they want is their account – their system – their reputation – associated with a breach.

There is also a concern around something ‘getting in the way’ of an admin and theoretically hindering their ability to resolve an issue. The truth is, when deployed correctly, there is no higher a probability of this occurring with a PAM than without.

The migration to a PAM solution provides something that you very rarely get these days – a chance to start fresh. A majority of the work involved with deploying a PAM infrastructure typically revolves around verifying system access and configuring such access in the solution.

Generally, this involves reviewing all access credentials to the various systems and verifying the authorized users have appropriate levels of access. This also provides you a perfect opportunity to begin monitoring each system with a UBA tool as you now have a clean starting point associated with those credentials.

If, as in many places, the approach to a PAM rollout is slow and methodical, then by following parallel paths, you can have a fully functional UBA solution as you finish up the PAM deployment. While this is perhaps a nirvana-type approach, it doesn’t mean that you cannot achieve the same end goal if you already have a PAM in place.

One key aspect of a UBA deployment is the time needed to model the user base. Typically, this is in the 60-90 day period before you have a level of assurance that you are seeing everything a user does. Remember, as with any type of analytics process, the longer the model runs, the better the predictability and the stronger the reliance that can be placed on the outcome.

While most UBA solutions can start alerting on questionable behavior within a few days, the long-term results will be far more actionable. If you think about how your workplace functions, there are likely monthly/quarterly/annual activities that will eventually make it into the model, so when Sally from Finance accesses that reporting server the 3rd day of every month, it will be treated as normal and not cause a false-positive alert.

This ‘Time to Learn’ is a key aspect to consider when deploying a UBA solution. Does the tool model other similar users in order to detect what is normal for the group compared to the individual? Is there one Windows Admin who logs into a Linux box every day at 2am, but none of the others Windows Admins do? While it could be a legitimate activity, it could also be an indicator of someone doing something malicious… Only ‘Time to Learn’ will tell.

That said, it is the intersection of these two solution sets that truly provides a level of user-associated risk mitigation that many of us strive for. Whether dusting off your ‘installed-but-rarely-used’ PAM solution, or implementing one fresh, the relationship between it and UBA cannot be overstressed.

While both PAM and UBA solutions have their individual merits, from an overall risk perspective, the benefit of both far exceeds what even most vendors perceive as value. Understanding that UBA is most beneficial when it can model clean accounts, and knowing how to leverage a PAM solution to ensure it is, results in one of the rare opportunities when One plus One actually does equal Three.

Fred Sanford was right.

The post It’s All About the User appeared first on Security Current.

In the third and final installment of my Open Letter to Vendors, we’re going to take a look the technology challenges that many vendors overlook. This isn’t about the bits and bytes, but rather around the considerations we face when looking for a solution and the challenges we confront when it comes to implementation.

So, now let’s talk tech…

An Open Letter to Security Vendors – Part III

There are three fundamental points that most startups – and many vendors in general – overlook when developing solutions and tool suites. You may have come up with a great solution to a problem, or a new, cutting edge way to analyze network traffic, or some other way to address the risk in my environment. However, what you really need to remember when you think about your solution set is this:

It’s disruptive, it’s complex, and it’s operationally intensive.

I’ve seen a lot of potentially amazing products fall by the wayside because the product teams had forgotten about one of these three facts. There is an old AppDev adage that goes something like “We can do it fast, we can do it good, and we can do it cheap…. pick two.”

Unfortunately, too many product teams fail to realize this adage doesn’t suffice in the security realm. While most of us hardly expect to drop a solution into our infrastructure and expect perfection (regardless of what the marketing types say), we do expect some consideration to be given to how we are going to live with your solution for years to come. I’m not buying a pen test that I can find someone else to do next year; I’m putting in a solution that will likely hit end-of-life in my data center.

Let’s take each point one by one.

Your solution is disruptive:

The vast majority of security solutions are, by their very nature, disruptive. While there are certain aspects you cannot avoid, finding ways to ensure your solution causes as little disruption as possible is a key ‘win’ for you.

At the absolute minimum, standing up an appliance or server takes time and effort, but when you layer on a ‘blocking’ mode, people start having cold sweats. Invariably, there is someone on the team that’s had a bad experience with an IPS/Proxy/Firewall deployment that supposedly caused a business outage, with which you will be compared.

While very few of us would entertain the idea of tossing a new solution in front of a revenue generating application without running it non-intrusively first, there are things that product teams need to consider about how potentially disruptive any solution is.

IPS/IDS, Proxies, Database Access Controls, Anti-malware sandboxing – all of these have the potential of disrupting business flow in some way, but let’s not forget about other more benign solutions like SIEM and Big Data solutions, which want to ingest terabytes of data. If you think pushing all those logs to a server isn’t disruptive to the network, I have some network engineers I’d love for you to meet.

One last consideration for the disruptive argument. Agents. Are. Bad. Please re-read that again – and again if need be. I have no doubt that my infrastructure teams would chase me down the hall with pitchforks and fire if I were to suggest we push yet another agent onto the endpoints.

So when I look for a solution to a problem, anything that doesn’t include an agent gets points above those that do. While there are unquestionably times when some type of agent is needed, please make sure you absolutely need it. Most operating systems these days allow you to interrogate activity over the network, so unless it’s absolutely necessary, try to find a way around the endpoint agent.

Your solution is complex:

With the possible exception of a password-vaulting app on my phone, every security solution out there has a level of complexity that was not considered during the marathon, late night, Mountain Dew driven coding sessions.

You are a trusted solution that will be potentially buried deep within my infrastructure. What part of that model makes you believe it would be ok to expect to HTTP (or worse, FTP) data from the internet? How about being proxy-aware and acting like a normal client? Is that too much to ask? What about high availability (HA) and redundancy? If you’re deployed in a HA environment, do the two devices need to be hardwired together or can they be geographically dispersed?

And let’s not forget my favorite “gotcha” of all… If your customer support crew cannot articulate all of the ports and services that are required across the infrastructure for your solution to function, then You. Messed. Something. Up.

It’s also important to understand how your integration with the rest of the infrastructure is going to happen. LEEF/CEF log formats, JSON/REST API’s, or STIX/TAXII data interchange formats are solid wins that should be considered from the beginning – not something tacked on at the end. Don’t ever forget you’re part of a larger ecosystem and you must play well with everyone – or you’ll be banished from the playground…  And this brings me to my final point……

Your solution is operationally intensive:

In the words of the immortal Rod Serling…

Imagine for a moment, if you will, being surrounded by a cornucopia of LCD screens, the missile-command like complexity of persistent and never ending assaults against your network. To your left, the screaming stream of log events traversing the screen at blinding speed. To your right, green, yellow, and red boxes flashing angrily as your hosts are poked, prodded, and tickled. Tickled into giving up that tiny bit of data that would provide the assailant with their next foothold. You, the lone defender in this never ending war, absorbing the mountains of data before you as you attempt to deduce your opponent’s next move as if you were Bobby Fischer studying a chess board…

Your next move could have you home on time for dinner, or forever stuck in..

The SOC Zone.

While admittedly a bit dramatic, all too many solutions providers fail to understand the operational complexity they introduce into the enterprise. Think about how the folks in today’s security operations center are inundated with information. Think about how the vast majority of InfoSec teams are understaffed. Think about how critical time is when dealing with an incident.

These are all things you need to look at when designing, enhancing, or selecting features to develop. Because if the end users choose not to use your product due to the complexity, then you lose – period.

Remember, you are supposed to be a trusted partner working to achieve mutual success, which ties directly to how much of an impact you are to my team. How much overhead does it take to keep your solution up-to-date? Do we need to do ‘fresh installs’ to do a version upgrade? Do we need to keep an old version of a browser or java around because you haven’t certified on the most recent version? Does it involve a thick client on the desktop to use?

These are all considerations that go into the decision process when selecting a solution and a partner. The more operationally intensive your solution, the less likely you are to gain points.

So, all of this said, how do you avoid the tech pitfalls that burn all-too-many solutions?  Perhaps some of the tried-and-true methods below will give you some ideas that you can apply to your own development process. In no particular order:

• Implement a Beta program: While many of your customers can’t run beta code in production, some will be able to and others will have labs that they can use. Be selective and keep it limited to only those customers who truly want to partner with you by providing feedback, logs, sample reports, etc. Here’s the caveat – you need to take your beta sites seriously and listen to their feedback. Typically, they will require a little extra TLC due to the instability of the codebase, but they will also help you weed out bugs and usability challenges before the official release ever hits the street.
• Institute a Customer Advisory Board (CAB):  A Customer Advisory Board is incredibly useful in garnering honest feedback not only about a solution, but also about your marketing efforts and sales positioning, as well as providing industry insight. Putting together a CAB requires support from the entire company – all the way up to the CEO – in order to be successful. A well thought out CAB will include great customers, unhappy ones, and non-customers alike. Consider the value you get from hearing about why someone did not choose you or why a long time customer is unhappy.
• Designate one release a year for operational improvements: Make one release a year focused on operational improvements rather than what you perceive as product enhancements. Can you make a frequently used feature more readily accessible? Can you automate some repetitive tasks so the users don’t need to go through the effort? Having one release each year focused on improving the usability of your solution goes a long way in retaining happy customers.
• Post-implementation Satisfaction Surveys: I’m still at a loss as to why more companies don’t do this. It is so incredibly easy to setup a web-based survey that there is really no excuse as to why you don’t ask for feedback about how the implementation went. Were there any challenges with the install? How did the support team do?  Any suggested changes to the process? All valuable questions.

So there you have it. Hopefully this provided some insights into what we see from this side of the desk and you gained valuable takeaways from the series. Perhaps your next marketing deck won’t be about your CEO’s experience with startups, and your sales rep will earn trust when he looks a potential customer in the eye and says, “Sorry, we don’t do that yet,” or maybe your next release will make my team’s job a bit easier.

Only time will tell.

The post An Open Letter to Vendors — Part 3 appeared first on Security Current.

In Part I, I gave you some food for thought about getting your message out there in a clean, crisp, and concise way. In the second installment of my Open Letter to Vendors, we’re going to take a trip to the magical and mystical island of InfoSec Land, where sales are based on trust and functionality, and the sales cycle takes longer than the modern day election campaign.

An Open Letter to Security Vendors – Part 2

As the security market explodes with new vendors, there has been a correlated influx of ‘experienced’ sales folks calling on CISOs. More and more, I find myself running across sales executives who came into security sales from other markets. Software sales, hardware sales, outsourced services – you name it and likely we can find a sales person jumping on the InfoSec bandwagon.

Unfortunately, many of them think that selling security products is much like selling anything else – make a better deal than the competitor and you get the sale.

To all of those folks, I have some advice.

Most of us don’t want vendors – we want partners. We want to work with people who care about both organizations being successful, not just one or the other.

Partners are not people who call me once a year to see if I got the annual invoice and wonder when they can receive payment – those people are called vendors – and they have a very short lifespan.

A partner works with my team to ensure we are getting the full picture – about your solution, general industry topics, or local going’s on. Partners are invested in our mutual success and they are the ones I call first with any new opportunities. Partners have a mutual TRUST that is imperative in this industry.

This is the point most sales and marketing efforts fail miserably on, especially at the beginning of the sales process. I need to trust you, your product, and your company. Security professionals live and die by trust, and if we don’t have it in you, your time in this world is limited.

Trust is not defined by whether or not I’ve accepted your LinkedIn invite, or you scanned my badge at some event. Trust begins at that moment when I ask about a feature that may be road mapped, planned, or not even thought of – and you tell me the truth. The second you start to dance around the answer is the precise moment you lose a sale.

There is really no sense in telling us your solution does something it doesn’t. We’ll find out the truth during the product test, so why not just be upfront from the beginning? This is especially true for the startups.

If you roadmap a feature that’s a few months away, be upfront about it. We’ll likely still run the evaluation and look for the feature when it’s released. However, telling us you do something you can’t will only get your equipment returned and get you labeled as untrustworthy – not really something you can afford in a trust-based industry.

The second point that most “experienced” sales and marketing professionals miss is that your goal isn’t to sell me a product – your goal is to get me to agree to a proof-of-concept. If your technology is as good as you say it is, it will sell itself. I don’t buy a house without walking through it, or a car without taking it for a test drive, so why would you think I’m dropping seven figures on a product without knowing how it works in our infrastructure?

You’re not selling widgets or bedazzled phone covers – you’re selling a solution that I am staking my and my company’s reputation on. Enough with the marketing fluff and F.U.D. – if you want my attention tell me what you do. Because the reality is… you will go through a thorough proof-of-concept well before I ever decide to write you a check.

Here’s what you need to remember. Every company, every infrastructure, and every security program is different. I frankly don’t care if your solution worked in some Fortune-100 corporation or if my competitor deployed it. I care that it works in my world, with my technology, and satisfies my requirements.

You can package it up as nicely as you want and put a big red bow on it if you need to, but understand that your solution will likely not just drop into my environment and fulfill all the promises of your latest marketing campaign. And please, for your own benefit, don’t put me on a pipeline report just because I’m doing a proof-of-concept, because odds are, it will be a different calendar year before you see a sale.

Oh, and to all the CEOs and EVPs/SVPs of Sales out there? Understand that this is a process – and a long one at that. The truth is, unless it’s a Chicken Little purchase, there is a very high probability that I’m evaluating your solution for a strategic deployment and that we will likely have a new President before you can submit an invoice.

So, based upon the way my inbox exploded with MadLibs following Part I, perhaps a light sales-centric exercise will help you determine if you are really sending CISOs the right message.

If you dare, one morning over coffee, spend some time on your own website and see if you can associate the functionalities detailed on the site to an actual capability in your product. Can you clearly articulate how the functionality is provided? Can you look a prospective customer in the eyes and explain it?

Perhaps this could also be a management exercise – take your newest ISR and your most seasoned sales executive and ask them to visit your own site as a customer does.

Can you connect each piece of functionality detailed on your site to an existing feature set of the product suite? Is the site correct? Is your sales pitch? Are neither?

Look – it’s simple. In today’s hyper-competitive security space, you want to give yourself every opportunity to win a deal or, conversely, you want to avoid the pitfalls that will knock you out of consideration.

It really wasn’t all that long ago when we had two choices of firewalls, or maybe three IDS vendors and a handful of SEIMs to consider. Now there are countless firewall/next gen firewall vendors who offer onboard IPS/IDS, Proxy, and anti-malware solutions all in a single device.  The point being that our world is rapidly changing and those with the budget have more options than ever. Why alienate yourself by promising a diamond and delivering coal?

Okay, so we’ve touched on Marketing in Part I and Sales in Part II.  In the next and final installment, we’ll touch on the technology that’s being proffered as my ‘Solution to root out the evil doers hidden deep within my network….’ or some such thing.

This is going to be a fun one…

The post An Open Letter to Vendors — Part 2 appeared first on Security Current.

So tell me – did you hear the news?? Apparently the rumors are indeed true.

2015 is the year of the Security Startup.

And in the words of the greatest British comedy troupe ever… and there was much rejoicing …

However, after meeting with dozens of startups at Black Hat a few weeks ago, I’ve realized that the vast majority of the leaders of these new companies struggle to articulate the value their solutions bring to the enterprise.

As many of us have, I have seen many new technologies in the security space that promise to ‘solve all of my problems’ or ‘revolutionize the space.’

Sadly, most of them have gone the way of the Betamax – superior technology that suffered from poor implementation.

I am fairly often asked a basic question by many vendors: “As a CISO, what does it take for a startup to get your attention?” While it seems like an innocent question, the complexities of the answer typically result in glassed-over eyes, fidgeting, and even the occasional ‘hey, let me introduce you to…’ blow-off.  Rarely will there be a person who wants to hear the real answer.

Most successful security executives know that effective programs are more than just a suite of tools, but rather the integration of people, technology, process and education. None of these can be substituted for the other, but they can enhance and augment one another to provide a greater good.

Tools allow my team to be efficient, expedient and productive. Much to the chagrin of most vendors, tools are not, and will never be, my silver bullets. By themselves, tools do not a security program make, but each can be a solid piece of technology that is implemented in such a way to allow my team to the best use of their skillset.

So, in a slight change of pace, the next few columns are going to be an ongoing open letter to vendors of all shapes and sizes, but particularly to startups. The goal is not to be a soapbox, but rather be that cold-bucket-of-water-to-the-face to the CEO/CTO/Product Manager of all of the vendors in the space.

So to all those sales, marketing and start-up types that truly want to know how to get our attention, read on…

An Open Letter to Security Vendors – Part 1

What better place to start then with what is typically a CISO’s first introduction to a solution – the sales & marketing teams. On an average day, I get hundreds of emails, many of which are business related. However, an inordinate number of them are sales and marketing materials.

While I’m sure your solution is great and the technology is revolutionary, in no way, shape or form do you have my ‘silver bullet.’ Your solution will not ‘make me sleep better,’ ‘reduce the overall risk to my infrastructure,’ or ‘give me granular insight into my threats’ – and do you know why? It is because you don’t know what my concerns are. You don’t live in my world or understand what my challenges are and presuming that you do is the first step to the Betamax graveyard.

Also, stop trying to scare me into a purchase. Yes, I have read the recent (insert vendor name here) Data Breach Report or the latest (insert analyst name here) Research Report. I don’t care what quadrant you’re in or who says you’re a leader in your space – all I care about is how you’re going to reduce the risk in my environment, and if you can do that in three sentences, why wouldn’t you?

So, to those CEOs/CTOs/Marketing Execs and sales folk, I say this with all sincerity and honesty…

Mad Libs^© are your friend.

I was recently discussing how many startups have a ‘Lack of Message’ problem with a friend, who happens to be one of the few sales executives in the industry I trust. She just laughed and said, ‘They’ve forgotten what Mad Libs are.’

It was an epiphany.

Do you remember Mad Libs? The silly little books of unfinished stories you had as a kid that invited you to input missing keywords with pronouns, verbs, or adjectives? That’s what’s missing from most of today’s interactions between companies and CISOs.

We don’t want your life story, or to hear about your decades of experience running companies, or the brilliance of your algorithms – we want to hear about how you’re going to address a problem we have. If you do solve one of our pain points, we will want to hear the rest of the story. But your CEO’s 30-year tenure of running a Fortune-1000 company doesn’t matter to me if your solution doesn’t meet my needs to begin with. Tell me how you will help – then the rest will come.

I can’t tell you the number of vendors I met at Black Hat that lost my interest in the first five minutes, only because they felt the CEO’s credentials meant more than the solutions functionality. Are their solutions promising? Perhaps – but since you spent all of your time telling me be about your angels and executive team, I’ll never know. If you had made those first precious 15 seconds more valuable for me, at least I’d know what you do.

So, here’s a little InfoSec Mad Lib to get you started.  Try it out and see if it will work for you.

Hi, my name is _____ and I am the _____ of _____. Our company’s goal is to help you _____ by providing _____ that will _____.  If you are dealing with _____ in your environment, we would love to demo our _____ solution and see if there is a fit.

Here’s a real-world example:

Hi, my name is John Smith and I am the CEO of TrustMe. Our company’s goal is to help you gain control over privileged users by providing a secure proxy that will manage, log, and report on all Admin and Root access. If you are dealing with uncontrolled administrator credentials in your environment, we would love to demo our SecureAdmin solution and see if there is a fit.

There you go. Three sentences and 15 seconds that will hook the vast majority of security executives into at least giving you a direction. Perhaps they are dealing with it and want to hear more. Perhaps they have already addressed the issue and aren’t interested. Either way, you’ll know your next steps, less time is wasted, and after all, isn’t that what we both want?

More to come in Part II…  Stay Tuned.

The post An Open Letter to Security Vendors appeared first on Security Current.