New SecureState Blog

Check out our new blog site here!

Read more!

Do Your Homework

Every one of our competitors says they perform penetration testing. We’ve found that what they call penetration testing often times is nothing more than a vulnerability scan with automated tools.

Read more!

Why You’re Probably Not Ready for DLP Software

Data Loss (or Leakage) Protection (DLP) has been a hot topic for a while now, and while as a concept DLP has a lot of merit, most organizations are not ready to implement.

Read more!

Reassess Your PCI Scope: Virtual Terminals

At the annual PCI Community Meeting in September, the PCI Security Standards Council (SSC) made it clear that interpretation of the standard and requirements has not been performed in the same manner throughout the industry. Some of the goals of the new standard are to improve verbiage in order to clarify the intent of individual requirements and understanding how to scope your cardholder data environment. From my review of the Payment Card Industry (PCI) Data Security Standard (DSS) version 2.0, things are definitely clearing up.

Read more!

A (quick) theorem on the symbiosis of Risk Management, Security, Operations, and Audit in a mature Security Program -or - How I Learned to Stop Worrying and Love the Venn

Recently I had a conversation with a colleague about the relative symbiosis among organizational divisions and how it always plays a huge role in the effectiveness of a given process. We agreed that this is particularly true when that process involves securing information that is critical to the business. Because of the importance of segmenting responsibilities between groups, the protection of information brings about many unique challenges that can call into question divisional roles. For example: Who within the organization defines what information is critical? Who within the organization is responsible for the actual implementation of security controls? Who confirms compliance to agreed-upon standards? Who is in charge of accepting risk for the organization? And perhaps most importantly, how should these groups or individuals align and interact with one another?

Read more!

Padding Oracle Attack

Whenever I talk about the ASP.net padding oracle attack the common response is “we don’t use oracle.“ While Oracle has its own list of vulnerabilities this is not the oracle we will talk about here. The padding oracle attack has been out for a while in applications such as ruby on rails and JavaServer faces. It has gained recent fame due to the discovery of it affecting ASP.net. This vulnerability was so serious Microsoft put out an out of band or emergency patch. Before I go any further, stop reading and PATCH your systems.

Read more!

SAQuestionable

Although the PCI regulation is great for making companies which otherwise would do nothing with regard to security do something, I often find myself questioning the logic of the Payment Brands. Merchants that fall below a Level 1 or rather have a transaction volume less than 6 million annually (with regard to VISA, Mastercard, and Discover transactions) only have to fill out a self assessment questionnaire in order to show PCI compliance. As of right now, there have been no formal qualifications/guidelines for those filling out the SAQ. In other words, the Payment Brands have not defined a specific skill set or position within an organization that should be responsible for filling out this questionnaire.

So essentially, anyone from internal audit to network administration may have the responsibility of filling out this SAQ. Next year this will change for Level 2 merchants (between 2 million and 6 million transactions) that take MasterCard transactions when MasterCard starts requiring these organizations to have either an onsite assessment performed by a QSA or someone officially trained from that organization to become an Internal Security Auditor (ISA). Although I commend Mastercard for taking this additional step and I hope other payment brands follow suit, shouldn’t those responsible for filling out the SAQ in any size organization, whether you are a Level 2 or a Level 4, be qualified to do so? Doesn’t requiring only Level 2 merchants to have someone undergo appropriate training, imply that an individual in a smaller organization who is filling out an SAQ does not have to be qualified? This is pretty scary when you consider that it is a matter of one credit card transaction that could keep you from meeting that 2 million transaction threshold.

Look, all I am trying to say is that more times than not, I am seeing that companies are assigning someone to fill out an SAQ who does not have the security expertise to properly assess whether controls are implemented in accordance with PCI. These individuals think they understand the control requirements but most times do not. Is this a knock against these people? Absolutely not. Most times these individuals’ job functions don’t require them to have the needed security experience to properly assess their cardholder environment.

I understand the reasoning behind using the SAQ, which is: smaller organizations may not have the budget to have an onsite assessment performed. Unfortunately, there is a cost associated with doing business. In my opinion, if you as an organization choose to take credit cards, than you also choose to become PCI compliant. This should, in every instance, entail bringing in a 3rd party to assess those controls; after all, does GLBA or SOX allow a company to fill out an SAQ?

Read more!