When considering the alarming number of mega-data breaches and other such security incidents as they occur almost daily, and then compare the announced "root causes" and "used attack paths" of the incidents with the current state-of-the-art strategies to defend against attacks, I have come to conclusion that, unfortunately, security (risk, audit, and compliance, and any other assurance functions) is more often than not only "cementing" the status quo, that is the currently used processes or ways of doing business in a somewhat "secure" fashion.
For example, when POS (point-of-sale) units are in focus, then security professionals start to think / talk about:
- Network segmentation to keep the POS terminals as much as possible out of the corporate network or other locally connected networks and therefore out of the scope
- Encryption of cardholder data (Primary Account Number [PAM], cardholder name, expiration date, service code) and of sensitive authentication data (Full track data/chip, CAV2/CVC2/CVV2/CID, PINs/PIN blocks)
- No storage (do not store sensitive authentication data after authorization, even if encrypted)
- And all of the other 12 major requirements of the Payment Card Industry Security Standards Council (latest versions).
Often the security professionals may not get much further because business leaders don't want to spend the extra money needed to upgrade the infrastructure and so "accept" the risk on behalf of the unsuspicious consumers.
So basically what we're dealing with here is that the process of payments using credit cards between the consumer, the merchant, and the bank is not really secure, and both the merchant and banks need to either secure it or risk the consumer's money, data, and reputation (including that of the bank). This is why regulations and laws need to be put in place to protect the rights of the third-party consumer/customer. However, no one seems to think about better processes to perform electronic remote payments.
Another example is in the HIPAA realm with its Privacy and Security rules, further defined by the HITECH act that addresses the handling and (non)disclosure of "Protected Health Information" (PHI) of individuals. While the Privacy Rule deals with covered entities, use-cases, disclosures, and administrative requirements, compliance dates and enforcement penalties, the Security Rule describes the technical and non-technical safeguards that covered entities must install and maintain to secure individuals' "electronic protected health information" (e-PHI) — note the emphasis, PHI transmitted orally or in writing is not covered!
The Security Rule then makes references about the typical C-I-A (Confidentiality, integrity, availability) tuple, threats, misuses, impermissible disclosures, and compliance, and then defines risk management (analysis) as the underlying security management approach to administrative safeguards, in addition to workforce training and assigning a security official. Again we have the situation that two (or more) parties deal with data affecting a third-party — the patient/customer — whose privacy and health information is on the hook if they mess up.
Sign up for CIO Asia eNewsletters.