FIPS 140-2 in a Nutshell

  The US Federal Government requires that its agencies protect sensitive, but unclassified information using cryptographic modules that have been validated to Federal Information Processing (FIPS) Standard 140-2 “Security Requirements for Cryptographic Modules.”  This standard replaced its predecessor, FIPS 140-1.  In this context, the term “validated” means tested by accredited … Continue reading

The Trust-Value Equation

  “I must trust that the benefit that I gain from using your service exceeds the concerns (Fear, Uncertainty, and Doubt) that I have about using it.” Benefit can be thought of as a ratio of utility to unfriendliness.  No matter how user-friendly an application is, if a customer gains … Continue reading

The Encryption Magic Bullet

This post is a response to a variety of discussions that I have had lately with a variety of customers, executives, salespeople, and even engineers that are working on security projects for a variety of companies.  Sometimes, it seems, that encryption is positioned as the “Magic Bullet” that will cure … Continue reading

SOC 1 vs SOC 2

I am frequently asked about the difference between a SOC 1 report and a SOC 2 report and why an organization would have both.  The SOC 1 replaced the SAS 70 report and was intended to be used for service providers to give to their publicly traded customers to assert … Continue reading

Define: PCI Service Provider

A PCI Service Provider is a “Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed … Continue reading

The Contracting Life Cycle

Just as there is a life cycle for software development, there is a life cycle for contracting and this cycle must be managed as well to assure information security for the organization.  While there are a variety of formal models promoted by contract management software vendors, the typical phases include: … Continue reading

Defense-in-depth, Part 2

Last post, I discussed the concept of defense-in-depth (DiD) where overlapping controls provide increased security, particularly if one of the controls should happen to fail. Now, I will give a specific example—host-based firewalls. Both the Windows and Linux operating systems have firewalling capabilities built into the OS. Frequently, I will … Continue reading

Defense in Depth

Security is hard because it requires attention to detail and getting the “blocking & tackling” right.  There are lots of cool and shiny security products on the market today.  Remember a “product” is not a “solution” until it is tailor-fit to meet the needs of the organization and properly maintained … Continue reading

Security Policy Exceptions

Not long ago, I was reading a debate on a forum discussing all kinds of edge cases that some participants were arguing needed to be considered in a security policy regarding some particular aspect of security.  In fact, I forget what the issue was, but it was clear that … Continue reading

  • The postings and views on this site are my own and do not necessarily reflect the positions, strategies, or opinions of any current or previous employer.