Archive for May, 2016

20
May
16

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.

11
May
16

Heads Up – Changes To SAQ A

I had a question this week regarding v3.2 of SAQ A that pointed out there have been some changes to that SAQ that people may have not noticed given the larger issues with the changes to the PCI DSS.  As a reminder, SAQ A is the least amount of PCI requirements any in-scope organization can comply.

Those added requirements to SAQ A are:

  • 2.1(a) – Are vendor-supplied defaults always changed before installing a system on the network?
  • 2.1(b) – Are unnecessary default accounts removed or disabled before installing a system on the network?
  • 8.1.1 – Are all users assigned a unique ID before allowing them to access system components or cardholder data?
  • 8.1.3 – Is access for any terminated users immediately deactivated or removed?
  • 8.2 – In addition to assigning a unique ID, is one or more of the following methods employed to authenticate all users?
  • 8.2.3(a) – Are user password parameters configured to require passwords/passphrases meet the following?
  • 8.5 – Are group, shared, or generic accounts, passwords, or other authentication methods prohibited
  • 12.10.1(a) – Has an incident response plan been created to be implemented in the event of system breach?

Even when a merchant outsources all of their card processing, these are controls that can still apply because in a lot of cases, a merchant is responsible for setup, management and maintenance of their outsourced payment processes and applications.

In addition, merchant employees will also interact with an outsourced payment system to handle chargebacks and disputes.  Those user accounts used by the outsourced environment will normally be managed by someone at the merchant, not necessarily the service provider.

In regards to incident response, the merchant will be involved with incident response even when they have totally outsourced their payment environment.  The merchant will work with their outsourcer to work through an incident and those responsibilities of the merchant need to be documented.

As a result, the addition of these controls should not be a surprise to anyone.




May 2016
M T W T F S S
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Months