Tag: Security

This ZDNET article, “Over 90 percent of data breaches in first half of 2014 were preventable”, had me intrigued but it was their summary that really caught my attention. Since the latest explanation of how the North Koreans hacked Sony was that they stole a system administrator’s password by some method that is not discussed but vaguely confirmed by the NSA, we would have to conclude that the Sony breach was probably a staff mistake.

The Online Trust Alliance says that a high percentage of data breaches were the result of staff mistakes — rather than external hacking.

According to a recent Online Trust Alliance press release about 47% of data breaches was the result of staff mistakes and 40% were the result of external intrusions. Here is what they said.

OTA also announced that it has analyzed over a thousand breaches involving the loss of personally identifiable information (PII) in 2014, as reported by the Open Security Foundation (OSF) and the Privacy Rights Clearinghouse. OTA found that only 40 percent were the result of external intrusions, while 29 percent were caused by employees—accidentally or maliciously—due to a lack of internal controls. The balance of incidents were primarily attributed to lost or stolen devices or documents (18 percent) and social engineering/fraud (11 percent).

There are a lot of loose ends with the Sony hack that bother old IT guys like me. Kim Zetter in the article, The Evidence That North Korea Hacked Sony Is Flimsy, makes the point that nation-state attacks are not normally this noisy. This attack was public and filled with revenge-filled rhetoric that sounded distinctly non-North Korean.

Marc Rogers in the article, Why the Sony hack is unlikely to be the work of North Korea, goes a step farther and says an insider is the likely culprit.

3. It’s clear from the hard-coded paths and passwords in the malware that whoever wrote it had extensive knowledge of Sony’s internal architecture and access to key passwords. While it’s plausible that an attacker could have built up this knowledge over time and then used it to make the malware, Occam’s razor suggests the simpler explanation of an insider. It also fits with the pure revenge tact that this started out as.

So if we are to assume that the attack is from North Korea, we have to ask when, why, and how did they plant a spy at Sony? The mainstream news media seems to be proceeding under the premise that the North Koreans could walk into Sony either literally or electronically and collect extensive knowledge of Sony’s architecture including key passwords in a relatively short period of time. I think this supports main stream media’s agenda that this is technology problem all we need to do is install the latest and greatest firewall. The reality is that this type of hack is typically an inside job so it is a primarily a personnel rather than a technology problem. In most major corporations this type of broad access requires lots of time since security is compartmentalized and transferring passwords to new people is dependent on developing trust. Password management in a large corporation like Sony can be further enhanced by delegating password control to different people. In this case the passwords for administering email, human resources and accounting systems are probably controlled and periodically changed by the people who have operational control of those systems. So if the insider working for the North Koreans is a new hire or contractor then they must have been inserted into Sony months ago. This begs the question of why did the North Koreans target Sony months ago, develop such a sophisticated operation, and then release detailed information about this operation to the world. All of this work for a movie! The North Koreans may be crazy but I do not think they are stupid!

If this hack is not North Koreans consumed by revenge over a movie, we have to conclude the insider was a long time employee or contractor who got the data directly off the servers or via malware installed on certain key computers. We are looking for a person with a Edward Snowden profile. Although some people who are skeptical of the North Korea explanation see a government conspiracy, my guess is our law enforcement agents are temporarily feeding the public misinformation to buy more time to complete the investigation and arrest the suspect while still in the United States.

For a detailed list of the Sony hack events check out the Riskbased Security article, A Breakdown and Analysis of the December, 2014 Sony Hack.

A couple of days I ago I wrote the post, Strengthening 2-Step Verification with Security Key, and yesterday I got the security key. I guess parcel post from France is pretty quick! I had to reboot the computer before I could get the hardware drivers to install. It took about two minutes to register the key with both of my gmail accounts after it finished booting. Pretty cool!

Today I tested it at work. The first step was to insert the security key and let Windows 7 install the drivers. Once again my luck installing the drivers was better after I rebooted. Then I cranked up Chrome and went to gmail. Google asked me to login. After I entered the password, it asked me to install the security key. In a couple of seconds it had validated and I was redirected to my inbox. I took the key out and put it back in my storage bag. Although I have entered my password several times as I browsed my security settings, it did not require access to the security key.

The last task was to create an app specific password for gmail for those applications that will not use the security key.

Last Wednesday my wife and I celebrated our 31^st anniversary at P. F. Changs. We had a nice dinner and they ran our card through a manual imprint system. Today I noticed that they wrote my CVV on the receipt. That is not necessary if they were actually going to process my bill as a manual credit card transaction in which the card is present. By writing the CVV on the receipt that means that they plan to process the charge later as a card not present transaction. For those of you who have jumped through the PCI hoops, you have to wonder what measures they are using to protect these receipts since they now include the CVV. In the PCI world there are some pretty serious restrictions on keeping the CVV information secure. This is a dumpster diver’s gold mine.

Okay, I am really annoyed. What is the best way for a company to continue their business after a data breach without annoying their customers? There are some interesting comments over at Krebs on Security but I have my own recommendation. As a long time developer I look for a good manual procedures to automate. In this case we are going in the opposite direction. We are breaking up a good automated procedure into standalone parts. In this case I would recommend creating a corporate web app to process the credit card transaction that would be very similar to the model used by internet retailers. In fact I would not be surprised if a corporate developer does not already have one they used to get through credit card processing certification. In this case either the waitperson or some other designated person enters the sixteen digit credit card number and CVV to run the transaction. If the transaction goes through then you update the bill in the restaurant’s order system with the confirmation code or reference ID. Is this a little more work? Yes but we literally have millions of people who enter their sixteen digit credit card number and CVV every day without exposing themselves to credit card fraud. There are a whole lot less PCI compliance issues with this procedure than a manual imprint with the customer’s CVV on the receipt.

I have been using TrueCrypt for several years. It is not the key cog in my security plan but it is helpful. The TrueCrypt development process looked trustworthy and professional. So I was shocked  with the developer’s announcement last week. It was just so weird, I thought the site had been hacked. The developer’s explanation on why he was stopping development bordered on incoherent. What does the end of Windows XP maintenance have to do with anything? As an old IT guy I decided to wait this mess out. There was an ongoing security review of TrueCrypt which should sort some of the issues out. For those conspiracy buffs out there, Snowden was a big fan of TrueCrypt. This weekend I decided to see if I could still download the source. It was not available at the normal location but I did locate it at Gibson Research Corporation who I recognize from Shields Up fame. Considering their reputation in the security game, they had some interesting some things to say.

Yes . . . TrueCrypt is still safe to use.

Although the disappearance of the TrueCrypt site, whose ever-presence the Internet community long ago grew to take for granted, shocked and surprised many, it clearly came as no surprise to the developers who maintained the site and its namesake code for the past ten years. An analysis of the extensive changes made to TrueCrypt’s swan song v7.2 release, and to the code’s updated v3.1 license, shows that this departure, which was unveiled without preamble, was in fact quite well planned.

For reasons that remain a titillating source of hypothesis, intrigue and paranoia, TrueCrypt’s developers chose not to graciously turn their beloved creation over to a wider Internet development community, but rather, as has always been their right granted by TrueCrypt’s longstanding license, to attempt to kill it off by creating a dramatically neutered 7.2 version that can only be used to view, but no longer to create new, TrueCrypt volumes.

Then, leveraging the perverse and wrongheaded belief that software whose support was just cancelled renders it immediately untrustworthy, they attempted to foreclose on TrueCrypt’s current and continued use by warning the industry that future problems would remain unrepaired. This being said of the latest 7.1a version of the code that has been used by millions, without change, since its release in February of 2012, more than 27 months before. Suddenly, for no disclosed reason, we should no longer trust it?

I will continue to use it until a better option becomes available. Although I doubt I will look at the code for security problems, I am curious what the security professionals find.

A document obtained by Computerworld from a reliable source indicates that Piedmont was presented with a list of 42 items that HHS officials wanted information on within 10 days. Specifically, Piedmont was asked to provide policies and procedures for:

1. Establishing and terminating users’ access to systems housing electronic patient health information (ePHI).
2. Emergency access to electronic information systems.
3. Inactive computer sessions (periods of inactivity).
4. Recording and examining activity in information systems that contain or use ePHI.
5. Risk assessments and analyses of relevant information systems that house or process ePHI data.
6. Employee violations (sanctions).
7. Electronically transmitting ePHI.
8. Preventing, detecting, containing and correcting security violations (incident reports).
9. Regularly reviewing records of information system activity, such as audit logs, access reports and security incident tracking reports.
10. Creating, documenting and reviewing exception reports or logs. Please provide a list of examples of security violation logging and monitoring.
11. Monitoring systems and the network, including a listing of all network perimeter devices, i.e. firewalls and routers.
12. Physical access to electronic information systems and the facility in which they are housed.
13. Establishing security access controls; (what types of security access controls are currently implemented or installed in hospitals’ databases that house ePHI data?).
14. Remote access activity i.e. network infrastructure, platform, access servers, authentication, and encryption software.
15. Internet usage.
16. Wireless security (transmission and usage).
17. Firewalls, routers and switches.
18. Maintenance and repairs of hardware, walls, doors, and locks in sensitive areas.
19. Terminating an electronic session and encrypting and decrypting ePHI.
20. Transmitting ePHI.
21. Password and server configurations.
22. Anti-virus software.
23. Network remote access.
24. Computer patch management.

HHS also had a slew of other requests:

1. Please provide a list of all information systems that house ePHI data, as well as network diagrams, including all hardware and software that are used to collect, store, process or transmit ePHI.
2. Please provide a list of terminated employees.
3. Please provide a list of all new hires.
4. Please provide a list of encryption mechanisms use for ePHI.
5. Please provide a list of authentication methods used to identify users authorized to access ePHI.
6. Please provide a list of outsourced individuals and contractors with access to ePHI data, if applicable. Please include a copy of the contract for these individuals.
7. Please provide a list of transmission methods used to transmit ePHI over an electronic communications network.
8. Please provide organizational charts that include names and titles for the management information system and information system security departments.
9. Please provide entity wide security program plans (e.g System Security Plan).
10. Please provide a list of all users with access to ePHI data. Please identify each user’s access rights and privileges.
11. Please provide a list of systems administrators, backup operators and users.
12. Please include a list of antivirus servers, installed, including their versions.
13. Please provide a list of software used to manage and control access to the Internet.
14. Please provide the antivirus software used for desktop and other devices, including their versions.
15. Please provide a list of users with remote access capabilities.
16. Please provide a list of database security requirements and settings.
17. Please provide a list of all Primary Domain Controllers (PDC) and servers (including Unix, Apple, Linux and Windows). Please identify whether these servers are used for processing, maintaining, updating, and sorting ePHI.
18. Please provide a list of authentication approaches used to verify a person has been authorized for specific access privileges to information and information systems.

Source: HIPAA audit: The 42 questions HHS might ask

Jeff of the HIPAA Blog talks more about the questions here and that the questions are pertinent to all firms with information security requirements.