BlueTooth is said to be at the heart of a gas station credit-card scam in the Southeast

Thieves are stealing credit-card numbers through skimmers they secretly installed inside pumps at gas stations throughout the Southeast, using Bluetooth wireless to transmit stolen card numbers, according to law enforcement officials.

“We’ve sent detectives out to every gas station within a mile of Interstate 75,” says Lt. Steve Maynard, spokesman for the Alachua County Sheriff’s Office

I suspect the “mile of Interstate” alludes to how the attackers are collecting the data.

It could be a dead-drop architecture instead, however. An attacker would come to a station and pickup all the numbers stored in the skimmer.

One of the biggest problems with payment card readers is how different they are from the surface of the device they are installed into. If the device had a flush/smooth surface it would be far easier to detect a skimmer or other device placed over the reader.

This attack shows how even a smooth and secure surface appearance may be bypassed. The attackers are said to have keys to get to the inside of the pump.

Maynard says criminals wanting to hide the credit-card skimmers in gas pumps must have a key to the pump, but in some cases, a single key will serve to get into many gas pumps. It’s not known whether the gas-pump skimming operation involves insiders. Law enforcement is encouraging gas-station operators to train video surveillance they may use on the pumps.

The need for monitoring capabilities is much higher when keys are non-unique. The device should notify the owner the date/time it has been opened. Surveillance of an area accepting payment is also a step to consider. These two combined would significantly assist an investigation.

Another good idea would be to start to require wireless monitoring around payment systems. This could be tricky at a pump station, since so many other BlueTooth devices could be present. My guess is a signal would still appear as too consistent to be payment related; it would be detected through off-peak or closed hours.

Wireless monitoring is not far-fetched. It is already required for anyone who needs to be PCI compliant. ATMs are increasingly wireless devices, so the technology is already being installed. They simply need to have detection capabilities added, and monitoring of course.

VMware has created a public cloud survey with a $5 coffee gift card incentive.

Our survey asks why you chose your provider, the type of workloads you’re running, if you use intermediaries with your cloud solution, and what you perceive as the biggest benefits or concerns when it comes to cloud.

Now is your chance to let the providers know that compliance and security are (or aren’t) your top concern.

The National Institute of Standards and Technology (NIST) today has re-released their Special Publication 800-53.

The document I just saw says it is Revision 1, with a June 2010 stamp on the cover.

This is confusing because the current version made available to the general public is listed as Revision 3. Here is the official copy on their website with all the changes clearly marked:

800-53-rev3_markup-final-public-draft-to-final-updated_may-01-2010.pdf

Note that NIST also posted an errata document that lists just the changes to 800-53. FISMAPEDIA gives a granular comparison between Revision 3 and Revision 2.

One big change that has happened seems to be related to FIPS 199 security categories — organizations now can use their own impact assessment formula or something like NIST SP 800-60 instead.

Another big change is the addition of the phrase “Existing organizational policies and procedures may make the need for additional specific policies and procedures unnecessary.”

A vast majority of the edits in the document are cosmetic (i.e. changing the term one-time to replay-resistant) but here are some I found interesting:

1. Pg 8, The supplemental guidance is explicitly said to contain no requirements
2. Pg 22, Removed the statement that a security officer acts on behalf of CIO
3. Pg 27, Changed the Risk Management Framework to “the organization’s approach to managing risk”
4. Pg 38, New statement on liability in the cloud: “If a security control deficit exists, the responsibility for adequately mitigating unacceptable risks arising from the use of external information system services remains with the authorizing official.”
5. Pg 38, New compensating controls statement for cloud: “Employing alternative risk mitigation measures within the organizational information system when a contract either does not exist or the contract does not provide the necessary leverage for the organization to obtain needed security controls.”
6. Pg 41, New legislation reference, going way back, already mentioned on pg 51: The Atomic Energy Act of 1954 (P.L. 83-703), August 1954.
7. Pg 43, Deleted ISO 17799 and replaced with 15408-1 through 3: Information technology — Security techniques — Evaluation criteria for IT security
8. Pg 52, Definition of defense-in-depth: Information security strategy integrating people, technology, and operations capabilities to establish variable barriers across multiple layers and missions of the organization.
9. Pg 54, Definition of hybrid security control: A security control that is implemented in an information system in part as a common control and in part as a system-specific
   control.
10. Pg 55, Definition of an internal network now includes the security technology implemented between organization-controlled endpoints
11. Pg 59, A surprisingly weak definition of removable media: anything “which can be inserted into and removed from a computing device”. That means anything to me. It should have reference to effort, such as “easily” or “designed to be”.
12. Pg 63, Definition of sensitive information: Information, the loss, misuse, or unauthorized access to or modification of, that could adversely affect the national interest or the conduct of federal programs, or the privacy to which individuals are entitled under 5 U.S.C. Section 552a (the Privacy Act), but that has not been specifically authorized under criteria established by an Executive Order or an Act of Congress to be kept classified in the interest of national defense or foreign policy.
13. Pg 66, Statement that all controls are required: The implementation of security controls by sequence priority code does not imply the achievement of any defined level of risk mitigation until all of the security controls in the security plan have been implemented. The priority codes are used only for implementation sequencing, not for making security control selection decisions.
14. Pg 79, Level of cryptography used may depend on level of personnel clearance
15. Pg 80, Encryption and “offline storage” added to AC-3 as supplemental guidance to reduce risk of unauthorized data disclosure
16. Pg 84, AC-7 Unsuccessful Login Attempts does not apply to devices that have no login such as removable media, unless that media is encrypted
17. Pg 90, AC-18 Wireless Access completely updated and references NIST Special Publications 800-48, 800-94, and 800-97
18. Pg 91, Unclassified mobile devices prohibited in “facilities containing information systems processing, storing, or transmitting classified information”
19. Pg 93, Portable storage media can be completely prohibited
20. Pg 94, Publicly accessible content includes information posted on any “organizational information system accessible to the public, typically without identification or authentication”
21. Pg 102, Time may be recorded as an offset of UTC
22. Pg 108, New guidance on interconnection between information systems. Use a contract or try to figure out an Interconnection Security Agreement
23. Pg 128, IA-2 Identification and Authentication: “Unique identification of individuals in group accounts (e.g., shared privilege accounts) may need to be considered for detailed accountability of activity.”
24. Pg 133, IA-5 Authenticator Management: “Organizations exercise caution in determining whether an embedded or stored authenticator is in encrypted or unencrypted form. If the authenticator in its stored representation, is used in the manner stored, then that representation is considered an unencrypted authenticator. This is irrespective of whether that representation is perhaps an encrypted version of something else (e.g., a password).”
25. Pg 195, SC-29 Heterogeneity: “Organizations that select this control should consider that an increase in diversity may add complexity and management overhead, both of which have the potential to lead to mistakes and misconfigurations which could increase overall risk.” Yes, do not attempt a dual-skin strategy unless you know what you are getting yourself into.
26. Pg 196, Completely new SC-34 Non-Modifiable Executable Programs
27. Pg 202, SI-4 Information System Monitoring includes “physical, cyber, and supply chain activities”

Still awake?

The Microsoft announcement that it is moving the cloud service into an appliance and semi-private service comes at the same time that the Amazon CTO calls private clouds “false clouds”.

Stepping aside from all the marketing about what is real and what is false, I think this move by Microsoft raises some great security and compliance questions.

First, I seem to remember Salesforce rumbling about this public-private service model as far back as 2005, around the time of the Google search appliance. The idea then was to take a web service and package it so it can receive updates but that’s it. This allows an entrance into a market that has a natural fear of getting into a service like cloud. It also helps reduce the expense of Salesforce trying to establish a meaningful cloud compliance or confidence message.

Microsoft is taking steps in this direction now. ComputerWorld reports that Muglia offers details on Microsoft Azure Appliance

Once settled in the data center, the appliance will be connected to Microsoft’s own instance of Azure. “We will maintain a flow of new software down to all of the appliances so they will be kept up to date,” he said, adding that the customer will retain control over factors such as when to apply updates and which services to deploy.

That sounds a lot like having another Microsoft product in a private environment that gets new software through the update service. Cloud? Ooops, nevermind I started to get into the definition again.

I am more interested to know what kind of logging, monitoring and access controls are in place. Naturally it is completely absent from the ComputerWorld article. The word “security” and the word “compliance” are not used a single time! Here is a good example question: does Microsoft, or Salesforce for that matter, maintain their own accounts with access to data in these appliances? That would make “change vendor defaults” for regulations and compliance very difficult to achieve.