The Bean Counters Many years ago, a car was manufactured with a design flaw resulting in the gas tank catching fire when the car was struck from behind. Many deaths stemmed from this mechanical flaw. It was later revealed during subsequent wrongful death court cases, that the vehicle’s manufacturer was aware of the problem, had performed a risk/benefit analysis, and determined the cost to fix the problem would exceed any penalty levied by the courts. As a software security professional, you may question – what type of software could result in a risk to life? Imagine, however, a faulty calculation in medical device’s software, possibly causing death if the calculation was significantly incorrect. Or aviation software, where the failure can

Earlier this week, (ISC)² announced that the DoD approved both the HCISPP and CCSP certifications to its DoD 8570 Approved Baseline Certifications table on the DoD Cyber Exchange website. Why does this matter? This means that the entire roster of (ISC)² certifications are now required for different security workforce categories within the Department, depending on the functional area the role covers. Approval for these additions came from the DoD Senior Information Security Officer and a recommendation by the Cyber Workforce Advisory Group (CWAG) Certification Committee. The HCISPP has been approved for the following categories: Information Assurance Manager Level 1 (IAM 1) IAM Level II (IAM II) The CCSP has been approved for the following categories: Information Assurance System Architect and Engineer Level

As a security practitioner, perhaps you have found yourself in meetings about Risk Management. Or, perhaps, you are part of the incident response team, where you are responsible for everything from preparation, through post-incident reporting. The common thread that runs through risk management and incident response are the “what if this happens” scenarios. Whatever your involvement in these preparatory exercises, the overarching concern of all involved is: When will the business be up and running normally again? When confronted with such dire circumstances, the realization of the need for Business Continuity and Disaster Recovery becomes as important as the business itself. These are no longer “what if” moments. When a business disruption occurs, it becomes a “what now” moment. When

Way back in 1975, two members of the Institute of Electrical and Electronics Engineers (IEEE) authored a report about how to protect computer systems. One of the recommendations in the report by Saltzer and Schroeder, “The Protection of Information in Computer Systems”, was to include “Fail-safe defaults”. If you work in any area of information security, it is time to consider what failing safely is all about. If you are a candidate who is studying for the CISSP exam, understanding the difference between failing safe, and failing secure, has even broader applications in at least two study domains.  In any capacity of InfoSec, it’s time for these seemingly overlooked “defaults” to gain higher stature in many of your layered defense

Pseudonymization is a de-identification process that has gained traction due to the adoption of GDPR, where it is referenced as a security and data protection by design mechanism. The application of pseudonymization to electronic healthcare records aims at preserving the patient's privacy and data confidentiality. In the US, HIPAA provides guidelines on how healthcare data must be handled, while data de-identification or pseudonymization is considered to simplify HIPAA compliance. According to GDPR, if pseudonymization is properly applied can lead to the relaxation, up to a certain degree, of data controllers’ legal obligations. Even though pseudonymization is a core technique for both GDPR and HIPAA, there are significant differences in the legal status of the generated data. Under GDPR, pseudonymous data