Archive for May 20th, 2016


Just Had To Comment

A friend posted to LinkedIn an interesting article from Dark Reading titled ‘Epic Security #FAILS Of The Past 10 Years’.  It is an interesting read, but I had to comment on a few premises that I found totally misguided or uninformed.

Perimeter Security

“But clinging to the old castle/moat model has been a wakeup call for many enterprises, while others (mostly SMBs) are still in denial that their old-school firewall stops hackers.”

Firewalls, intrusion detection and intrusion prevention technologies are proven to stop hackers from hacking organizations through the use of network attacks.  As a result, hackers changed tactics and went to the use of social engineering techniques such as spear phishing and the like to get around these technologies.  But because tactics change does not mean that these technologies are worthless.  What it does mean is that organizations relying on only these technologies need to understand the changes in attacks and respond accordingly.  As a result, firewalls, intrusion detection and intrusion prevention technologies all still have a place in the information security ecosystem.

Where they have failed is in their implementation and execution.  In too many organizations, the rules implemented by these devices are sloppy and loose.  Why?  Because of the mistaken belief that it is the only way to be flexible and speedy in our ever changing world of business.  Business needs to be educated that security is the result of thoughtful inspection of what is only absolutely needed to ensure that known risks are properly managed.  Taking knee jerk responses and just tossing solutions out are not the way you secure anything.  Any intelligent leader will understand those facts.

“The network perimeter is evaporating. Mobile devices, cloud, and now the Internet of Things, have sucked the life out of traditional, static “set it and forget it” network security, and the bad guys are bypassing the corporate firewall with spear phishing emails that land on the desktops or devices of end users.”

While I agree the perimeter is changing, there still needs to be a defined perimeter.  Otherwise, how do people know where their responsibilities start and end?  The media keeps talking about the disappearing perimeter, but in fact the perimeter will never disappear.  It is not my job to secure the Internet, but it sure as Hell is my job to secure my organization’s network.  I have to consider the threats the Internet and networks I do not directly control present which is why I need to set where my organization’s perimeter exists.

But even more disconcerting is this concept of a “static” or “set and forget” mentality.  When did any information security professional ever think that information security was “static” or a “set it and forget it” situation?  The mantra I was always taught and have passed along in my classes and presentations was “information security is a journey, not a destination”.

End Users

“You can’t patch end users, so what is left?”

Why is it that people throw up their hands and say such things?  There is no doubt that security awareness training is a disaster.  But why is that a fact?  Could it be that we only lamely implement security awareness training.  Who really, truly believes that annual security awareness training will be effective?  Anyone?

People can be “patched” BUT … it takes a LOT of time, patience and persistence.  Attributes that seem to never exist with most security awareness programs I have encountered.

The example I love to trot out is from my own experience.  Right after I got married, my spouse constantly badgered me over my lack of consideration over putting the toilet seat down after using the bathroom.  Years went by and the badgering continued.  It took probably three to four years, but I finally got it down and began habitually putting the toilet seat down after using the facilities.  I learned my lesson and continue to put the seat down even now.

The lesson here is that it takes time and consistent and constant reminders to change human behavior.  Are you really going to put your lame annual security awareness training up against my example and claim it is actually effective?  I seriously doubt it.

Organizations have implemented all of the technological solutions they need to protect information and their networks.  The only last risk that exists are the people that use and interact with those systems.  That is why the hackers have switched over to social engineering techniques.  Why go after hardened systems when people can do it for you?

For the most part and unfortunately, information security professionals are great technologists and lousy people persons.  We need to partner with human resources and industrial psychologists to develop truly useful security awareness training that is focused on changing peoples’ behaviors so that they are more aware of the risks they present to the technology they use and interact.  As information security professionals, we can identify the risks.  But we need to leave the actual training to the HR and psychologists so that it is done effectively.

Point-of-Sale Systems

Point of sale (POS) systems are a dead end.  Just as hackers have changed tactics, so has the POS ecosystem.

With the advent of encryption or tokenization at the swipe/dip of a customer’s payment card, POS systems no longer encounter sensitive authentication data (SAD).  Add in the fact that transaction processors also return back a token instead of the PAN to POS solutions, the POS is no longer a source of cardholder data (CHD).

Most mid-sized and large merchants have implemented or are in the process of implementing these technologies.  Within the next 12 to 18 months, these efforts will be completed and the days of huge merchant data breaches will have come to an end.

This leaves small merchants as the risk of card data breaches.  The question then is will there be enough cards involved to make hacking small merchants worthwhile as a source of card data?  Do not get me wrong, small merchants will be breached, but the value to the attackers will not be the gold mines of breaching a Target or Home Depot.  As a result, attackers will have to move to breaching transaction processors and banks for those big scores and will, for the most part, leave small merchants alone.

Java and Flash

I do not think I really need to comment of Flash.  I think the risks of Flash speak for themselves.

“Many developers had written applications based on older versions of Java or to a specific version of Java that if upgraded to its latest iteration, wiped out some features or functions.”

If rapid application development has a downfall, it is with Java.  In all of the years I have been doing security assessments, I have yet to encounter any organization that developed in Java that does not have a Java security problem.  It never ceases to amaze any assessor just how old some organization’s implementations of Java can be.

But it is not just the loss of features and functions that creates issues with Java.  Typically the larger reason for antiquated versions of Java is just the simple fact that organizations do not have the manpower, time and/or budget to go in and rewrite applications to get them to newer versions of Java every time Java gets updated.  As a result, Java applications sit at their old and potentially risky versions.

Developing mitigation plans for such environments is also challenging.  The most typical approach is to increase log data generated by the application to increase the likelihood that an attack against the application can be identified.  Changes are made to the application to identify key issues that could be indicative of an attack and to generate appropriate log data or messages that can then alert operations personnel to the potential attack.

Another approach is to lock down as much as possible the ports/services and devices that can communicate or invoke the application through firewall rules.  Obviously this is not a good approach for anything Internet facing.

The bottom line is, whatever an organization can do to mitigate or remove the risks of Java it should be doing.  And the risk because of Java should be assessed often to ensure that it is properly managed.


Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

May 2016