1,600 Security Badges Missing From ATL Airport in 2 yr period – NBC News

While not a complicated or strategic topic that I would normally highlight, this one bit of news is from my home airport and personally meaningful.

Basically the report shows that 1,600 badges were lost or stolen in a 2 year period. This seems like a big number (2.6%), but this is a control that should (and not highlighted in broadcast) secondary supportive controls, such as:

• Key card access review logs to prevent duplicate entries (i.e., same person cannot badge in 2x)
• Analytics on badge entries against the work shifts of the person assigned
• Access to areas not zoned for that worker
• Termination of employees who don’t report in 12 hours on lost/missing badge

There are safeguards highlighted in broadcast that are good, but easily modified to the point of not being any value, and include:

• Pin (can be easily observed due to tones and no covering)
• Picture (every movie ever shows how easy this is done)
• An old badge could be re-programmed and be a duplicate of another higher ranking / alternate security zone

Bottom line is organizations, especially those tasked with safety of human life, must have the primary and secondary controls in place. Hopefully the remarks of a minor risk are based on their security assessments with the considerations above (and more perhaps).

Article:
Hundreds of ID badges that let airport workers roam the nation’s busiest hub have been stolen or lost in the last two years, an NBC News investigation has found.

While experts say the missing tags are a source of concern because they could fall into the wrong hands, officials at Hartsfield-Jackson Atlanta International Airport insist they don’t pose “a significant security threat.”

via Hundreds of Security Badges Missing From Atlanta Airport – NBC News.com.

Also thanks to the new new aggregator (competitor to AllTops) Inside on Security or the clean new interface.

Best,

James

 

Moving forward: Who cared about encrypted phone calls to begin with…The Great SIM Heist

TOP-SECRET GCHQ documents reveal that the intelligence agencies accessed the email and Facebook accounts of engineers and other employees of major telecom corporations and SIM card manufacturers in an effort to secretly obtain information that could give them access to millions of encryption keys.

-The Great SIM Heist: How Spies Stole the Keys to the Encryption Castle.

This news made a number of people upset, but after studying it for several weeks and trying to consider the macro effects to regular end users and corporations I have reached a contrarian point in my analysis.

Who cared?  Nobody (enough)

Sure the implications are published and are known, but who ever considered their cell phone encrypted and secure mobile device? I don’t think any consumer ever had that feeling and most professionals that WANT security in their communications use special precautions – such as the Black Phone.

So, if nobody expected it, demanded it, and the feature was primarily used to help billing than what SHOULD happen moving forward?

• The primary lesson here is that our assumptions must be revisited, challenged, valued, and addressed at the base level of service providers
• Second, businesses that depend (if they ever did so for instance on mobile device encrypted communication) on such safeguards – must pay for it

I would be interested in others points of view on the lessons forward. I have spent a good deal of time coordinating with leaders in this space and believe we can make a difference if we drop the assumptions, hopes, and focus on actual effective activities.

Helpful links on the Black Phone by SGP:

• Welcome to Blackphone

  https://blackphone.ch/

  Blackphone was created by the best minds in cryptology, security and mobile technology.
  

• Blackphone review: putting a price on privacy – Engadget

  Oct 3, 2014 – The Blackphone is billed as a security- and privacy-first device, not one with a record-breaking spec sheet or award-winning design. It shouldn’t …

• Blackphone – Wikipedia

   The Blackphone is a smartphone developed by SGP Technologies

FedRamp on the Cloud: AWS Architecture and Security Recommendations

In December Amazon released a nice guide with architecture layouts + tips across the NIST 800-53 standard. This is an important tool for ANY business looking to accelerate their operations into a distributed system model.

I took a few things away from this PDF – the two are that every company moving to the cloud should read this document. It not only provides an architecture layout that is critical in planning, but it also has numerous nuggets of awesome sprinkled throughout – an example:

 Many of the SAAS service providers do not have a FedRAMP ATO, so using their services will have to be discussed with the authorizing official at the sponsoring agency. Pg 28 <– sounds simple, but very costly if done under hopeful assumptions of acceptance!

Regarding the need to harden a base system:

AWS has found that installing applications on hardened OS’s can be problematic. When the registry is locked down, it can be very difficult to install applications without a lot of errors. If this becomes an issue, our suggestion is to install applications on a clean version of windows, snapshot the OS and use GPOs (either locally or from the AD server) to lock down the OS. When applying the GPOs and backing off security settings, reboot constantly because many of the registry changes only take effect upon reboot.

A bit about the White paper as described by Amazon:

Moving from traditional data centers to the AWS cloud presents a real opportunity for workload owners to select from over 200 different security features (Figure 1 – AWS Enterprise Security Reference ) that AWS provides. “What do I need to implement in order to build a secure and compliant system that can attain an ATO from my DAA?” is a common question that government customers ask. In many cases, organizations do not possess a workforce with the necessary real-world experience required to make decision makers feel comfortable with their move to the AWS cloud. This can make it seem challenging for customers to quickly transition to the cloud and start realizing the cost benefits, increased scalability, and improved availability that the AWS cloud can provide

A helpful guide and glad to see a major Cloud provider enabling it’s clients to excel at information security operations, and in this case – FedRamp

The “appearance of trustability” on foo.Github.io

Github is an awesome repository system that is very popular. Basically if you want to work on something (code, a book, electronic files) and then allow others to freely make suggested modifications (think track changes in a Microsoft Word doc), GitHub is the new way of life. I have used on publishing a book, writing code, taking a Python course online, and others are using it at a scale to produce some of the fantastic tools you see online.

I recently saw a post (included below) that clarified how their encryption was setup. Basically encryption allows you to confidentially send data to another party without the fear of others intercepting, stealing, or modifying it. It appears though that for foo.GitHub.io they are presenting the appearance of encryption, but in fact do not have it. Meaning the actual files are sent in the clear.

This is a problem in our structure of security and compliance. Today we have regulations and industry standards that are designed to prescribe specific security safeguards and levels to ensure a baseline amount of security. If organizations don’t meet the true intent of the regulations, do only enough to pass inspection, but create an environment that is susceptible to basic attacks – the user (you and me) are the one’s who suffer.

While it is disappointing for an organization to setup something that clearly creates false trust and checks a box, it is more a call to action for those who operate these systems to embrace pride of the services they are delivering. Much as Steve Jobs desired the insides and outsides of a system to be done correct – the security of an organization should not just look but be right.

We must do better as owners, operators, and security professionals. Trust depends on indicators and expectations being met, and to violate that begs the question… what else is being done in the same manner?

“cben” comment below on github.com issues post:

Turns out there is no end-to-end security even with foo.github.io domain. Got this response from GH support (emphasis mine):

[…opening commentary removed…]

While HTTPS requests may appear to work, our CDN provider is adding and removing the encryption at their end, and then the request is transmitted over the open internet from our CDN provider to our GitHub Pages infrastructure, creating the appearance of trustability.

This is why we do not yet officially support HTTPS for GitHub Pages. We definitely appreciate the feedback and I’ll add a +1 to this item on out internal Feature Request List.

via Add HTTPS support to Github Pages · Issue #156 · isaacs/github · GitHub.

Best,

James

State of compliance vs. compliant, re: New PCI Compliance Study | PCI Guru

A new study was released by Branden Williams and the Merchants Acquirer Committee (MAC), and it is worth a read. One aspect that jumped to me is the percentage of compliance vs compliant rates shared in the study. The difference here is those who have represented being PCI Compliant through Attestations of Compliance (AOC) vs. those who have had their programs pressure tested by the criminals of the world, and been found wanting.

Here is the snippet from PCI GURU that highlights this state of discrepancy:

The biggest finding of the study and what most people are pointing to is the low compliance percentages across the MAC members’ merchants.  Level 1, 2 and 3 merchants are only compliant around 67% to 69% of the time during their assessments.  However, most troubling is that Level 4 merchants are only 39% compliant.

Depending on the merchant level, these figures are not even close to what Visa last reported back in 2011.  Back then, Visa was stating that 98% of Level 1 merchants were reported as compliant.  Level 2 merchants were reported to be at 91% compliance.  Level 3 merchants were reported at 57% compliance.  As is Visa’s practice, it only reported that Level 4 merchants were at a “moderate” level of compliance.

via New PCI Compliance Study | PCI Guru.

Here is the link to the report from Branden & MAC

Board of Directors, CISO, and legal should all care deeply that PCI (and of course and certainly other contractual agreements) security is achieved honestly. To often organizations view this like registering a car with the government. This is far to complex and impactful to people within and outside a given business. The cyber economic connections between proper, efficient, and effective security all lend to better products in the market and more focus on what the business is driving towards.

Is your program honestly secure and fully addressing these least practice principles?

Best,

James