44 practices for #security & #IT professionals, post #HackingTeam hack. #infosec #opsec #appsec #devsec

Go easy on me, but this should serve as a list of good security practices and habits for security practitioners and professionals, and even some IT professionals who are up for the challenge.

Okay, so call me paranoid, but I’ve been around the block a few times on this stuff.

General guidelines

1. Use strong passwords. I can’t stress this enough. This should go without saying, but don’t use a password like “kittens.”
2. If you’re storing passwords salt them. If you can, use unique salts.
3. Change passwords regularly. Added layer of protection. Also works to defeat rainbow tables in the event you don't salt.
4. Encrypt your volumes. If you’re not using it, then lock it. Nobody needs 400gb of online hacking wares at any one moment, unless of course they’re stealing it from you.
5. Use unique passwords. If someone gets your one password, then you’re pwnd. If you have multiple passwords, then it’s harder for someone to gain access to your multiple systems and do things like pivot. Yeah, it's not as easy as the one login for domain controller, but if you're breached, you'll thank me.
6. Don’t trust anything. I see people plug random stuff into their machines. If you are someone who is out in the field, then definitely don’t bring any foreign contaminants back into your domain.
7. "Check this out" <-- famous last words.
8. Test with a VM. If you hose the Virtual Machine's snapshot you can always revert to a safe snapshot. Make a snapshot of a clean system first.
9. Use a good Antivirus. This should go without saying, but a system that connects to other systems and networks needs other defenses than the ones built directly into the OS, unless of course you’ve written your own OS, then nevermind. While AV doesn't protect against everything, not having AV is going without protection.
10. Don’t trust end nodes. If you’re not physically there, you don’t know what you’re on.
11. Never use warez. If you're a pro, then buy the apps and write them off.
12. Use a connection other than your main office network connections to get to the web for work like pentesting. If you’re using the connection your servers get updates on for hacking a target you are asking for trouble. “Someone’s hacking us; and their IP reverse look-up has an Exchange Server.”
13. Use a read-only image for core systems. If you’re using a laptop, don’t put anything on the harddrive that can be used to monitor the system, instead use an image on a thumbdrive for the OS. It’s a lot “safer” because if someone gets your gear they don’t get your work. Also you can pocket a thumbdrive or store them in a safe when they’re not in use.
14. If you’re doing forensics work, store the results on removable drive. This helps to keep the evidence clean from contaminants. Also encrypt this device. See #4.
15. Keep records and logs. If something looks out of the ordinary it will be easy to spot. If you don’t, then you can’t tell what happened. And those types of postmortems are exactly that, a real postmortem.
16. In case of a hardware breach, sweep for foreign signals coming from the infiltrated system. If it’s off, yet broadcasting then that’s a hint that something is up.
17. Restoring a backup does not fix the issue that allowed a breach.
18. Be careful what you say or post, you never know when someone will paraphrase something or something might be used against you.
19. Use two-factor authentication where possible.
20. If you’re using social media, don’t use it from your operations center. "Look they has a Twitter, I wonder if I can get them to click on this malicious link?" Now they have your IP and your User Agent. Spearphishing anybody?
21. Use a different MAC Address than the one embedded in your card. Switch this from time to time and scan to make sure nothing has cloned your MAC. "I thought you change it?" This little trick can help throw off a would-be attacker from the type of device you're using if they're using your MAC to pinpoint.
22. If you’re connecting to foreign networks use a throw-away wifi card if you can’t change your MAC. This also helps with driver issues if someone knows the type of hardware you roll with and they are specifically targeting you.
23. If your operations don’t need web access, then keep them off of the web. Download patches on a different machine and rebuild the system image.
24. Stay up-to-date where possible. If some application, driver, system, or piece of hardware prevents this, then at least update everything else. Nobody likes getting nailed because of a 3-year-old exploit.
25. In regard to peripherals, if you’re not using it, turn it off. For example some bluetooth devices and systems only look for services. They don’t prevent attacks from non-disclosed services. Eg. My computer looks like your Bluetooth headset to your computer, but your computer gives me access to your computer because it trusts your headset. This could also work for mobile phones and other devices.
26. Also see #6. I’m not one for paranoia, but if it looks like it’s been tampered with, then you don’t want to trust it.
27. Mark your drives: just like bags at the airport, all thumb drives look alike. This goes for external hard drives as well. Think permanent and unique.
28. If you’re researching a specific piece of hardware use gloves. You don’t know where the user has been or in the case of a laptop, where the device has been. Also it helps to maintain the integrity of the scene and evidence in the event of escalation.

Offsite operations

29. Use a tunnel like a strong VPN, this way when you’re remote, you can at least make it harder for something to access your system. Also the bonus is your traffic is "encrypted."
30. Encrypt your traffic. If TLS is an option then use it.
31. Everybody can be traced. It simply takes time, but don’t ever assume a multilayered encrypted connection is non-exploitable.
32. Use Faraday bags where necessary. If it broadcasts you can stop fix that pretty quick.

Onsite systems

33. Use a RAID. So many times I go into an office and there is no redundancy for the important volumes.
34. Keep offline backups. If you’re working on a hot project, definitely keep offline backups. If you’re infiltrated and someone wipes your data you need to know what you had access to at that moment. Also this helps with issues like ransomware.
35. Keep offsite secured backups. This protects against fire, raids, and that odd instance where all of your equipment and assets are seized pending clearance.
36. Watch for unwanted traffic on your network (assuming you have one). If someone gets in to your system, then you are pwnd.
37. If you don’t have gloves and must use an infected system, then use your own keyboard and pointing device. Also this isn't a bad idea either because if the machine has a device with a keylogger built in, this is an added layer of protection. (I've seen employees fake an incident to capture an admin password on one of these devices). Found out because the Admin account was logged right back in 2 minutes after the admin left for the day. When asked, the employee confirmed they intended to install pirated software that required administrative privileges. 
38. Clone the drive you’re investigating before accessing (if possible). If you trigger something on that drive it may try to cover its tracks.
39. Just because it’s in a foreign language doesn’t indicate a foreign act. Stuff like Google translate lets people make stuff that looks foreign all the time. If you don’t speak the language ask someone else if it’s legit. It may be an attempt at obfuscation or even gibberish to throw off an investigation.
40. Scan the traffic and memory prior to disconnecting an infected system, unless the infiltrators are in the process of removing data, then immediately disconnect the system. If you can run memory forensics analysis on a system, then it might give clues as to how it was infected, what it is doing, who it was contacting or even simply what type of infection it is.
41. If something is removing data actively on a drive, then take the system offline (not down). If it’s memory resident attempt to kill the process. If that doesn’t work, try to break the process with injections.
42. Learn what everything on your network does and what its habits are. If something looks out of the ordinary it will be easy to spot. An example might be a VOIP phone trying to gain SSH access to other resources.
43. If at all possible use a Faraday cage to prevent external wireless intrusion. You don't really need to access your wifi from the parking lot do you? With a booster someone can access your network from a greater distance. If you can use exclusively wired networks in a setup, then that's the "safest" bet.
44. Layer your defenses, why only use one firewall? I mean if it's that important, then it's okay to have a little lag from proper countermeasures.

Hope this helps somebody. This security stuff can be a can of worms at times. Got anything to add or think I got something wrong, shoot me a message on Twitter: @cpattersonv1

Update:
While 44 is a good start, as I think of more I'll add them here. These are more for closely related to Good IT practices.

45. Know what's in the network rack physically. If something looks like it doesn't belong then it likely doesn't. This could be anything from battery back-ups to switches, routers, and I've even seen extra servers in a rack before. Famous last words "I thought it was ours?"
46. Take an inventory of known, purchased equipment. This helps with #45.
47. If systems are checked out, inspect them for exploits prior to checking them in. If the operating systems on the devices aren't using read-only images they could be infected.
48. Develop acceptable use policies for equipment and network access and enforce these policies.
49. If it's infected, then clean it. Nobody likes to be reinfected because someone found a spare drive laying around.
50. Record all of the MAC addresses for internal hardware expected to be on the network. For virtual machines document any custom MAC addresses as well. This helps in situations where someone has planted an extra device. Also it helps to see if an employee might have an unsecured device on the network by using an app like Wireshark.
51. Clean up the cable nest. It's a lot easier to spot a cable in rack that's out of place if the cables are grouped in an intuitive way for spot checking. All too often with a cable nest or wad it's difficult to find unwanted physical intrusion; especially in a place like a shared hosting rack space where an extra cable can find its way through the floor panels or from the overhead wire tray. While they might only be stealing bandwidth, they could be passive scanning.
52. Setup a camera on the server room: motion-activated "critter" cams that work in low light work well. Have it transmit to a service or device offsite when the system is triggered immediately, this will help with tampering. If at all possible, hide this in a different housing.
53. Use managed switches that support port isolation on the network. Get the kind that allow passive scanning at the switch level. While traffic might be encrypted you can tell where it's going at least. 
54. Actually configure SNMP and utilize it. This management protocol can really help with detecting intrusions and failed equipment which can present symptoms similar to certain attacks like DoS and floods.
55. If a network port is not being used, disconnect that node from the system at the rack or in the switch room. This way extra device access can be limited as an added layer of protection.

#DTSR Other potential reasons for Medical information breaches outside of what was mentioned in the 6-1-2015 podcast.

I'm just brainstorming here based on my observations of the medical system in passing, or rather flaws I’ve seen in dealing with healthcare in my own interactions.

Why?

Healthcare systems provide access to the same information people use for nefarious purposes like tax return fraud, welfare fraud, and identity theft. They are often not integrated, so each system will be standalone in each facility and only contain whatever security the company felt the system warranted. Not as in a single computer per se, but likely a thin-client network for a specific system. Custom systems have to be written to integrate these systems together, so where two independent systems are involved, there are really three points of possible non-secured entry, taking into account the custom system for integration.

In a lot of companies, in terms of development projects, someone will ask a question like “Is it only going to be used internally?” To which the answer more often than not is “Then leave it up the IT department to lock down the workstations and restrict access.” I’m guessing healthcare companies, like other companies often scrimp on costs as well, so if they weigh the cost of a breach versus the cost of a payout, it might not be worth it to build in the more expensive security precautions. In my experience, there is often an assumption that a medical company’s legal representation would far outweigh that of individuals and moderately sized groups. If this is true, then again, the financial benefit to not securing is still worth it to the shareholders (if we only look at the bottom line). If the responsibility for the loss of information doesn’t fall on the companies, then they are off the hook. Also, it might be up to the patient to prove beyond a reasonable doubt that this specific breach is what caused their identity to be stolen (unreasonable burden of proof).

Nobody is going to shut down a hospital because of an information breach.

The devil's in the details

Healthcare systems tend to contain some of the most complete levels of information. While a tax return will have information such as an address, an employer’s address, and potentially a phone number or bank account, medical records (depending on the system) will contain this information and more, such as connections to other patients in the same system, bank account information, payment information, insurance account information, and the family medical history. If it’s a family clinic, patients are likely to bring in their children for a checkup, so their information is in the system before it’s in a system like the credit system.

Points of entry

Individual healthcare systems are likely easier to hack. While there are guidelines, there are multiple points of entry physically. Someone can hack a system on the network where the developer didn’t think an exploit could take place: MRI machines, copy machines, fax machines, printers, network scanners, x-ray machines, etc. How often is someone left alone with a terminal in the room for great lengths of time while they wait? Even though a terminal’s locked down, someone could add a hardware keylogger and wait, and then retrieve it when the medical staff have left the room again, to allow the patient to get dressed. This arrangement typically doesn’t happen with the IRS systems.

Most of the insurance companies require referrals, so there is a higher incidence of the same information being out there. A single tax return for the year, versus four or five visits to multiple various doctor offices for something as simple as a broken finger: primary care physician, emergency room, specialist, quick care, etc.

Lack of detection

Another fraud aspect, not necessarily social engineering might involve billing someone for a service that has yet to be billed. So Alice goes the doctor to have an MRI, while the real medical system is working through all of the tape between the insurance companies, Bob sends Alice a strongly worded letter with a legitimate looking address and information for payment processing. Alice pays the bill thinking it is from the healthcare provider. If Alice takes this bill to the medical provider and pays it, they will simply apply it to her account when she tells them she needs to make a payment. They’re interested in getting the money, so they might not even look at the forged bill, but will instead go about asking the typical verification questions:

“Do you still have Company X as your insurance provider?” 

“What’s your Last Name?”

“When is your Birthday?”

Also the person may neglect to bring the fake bill with them, assuming it would be in the system, so there is less of a chance for red flags in non-tech-savvy systems.

Market research

Since companies aren’t allowed to share medical information on personal statistics legally without some sort of generic research (studies), having a database of information relating to specific demographics might be helpful if you were let’s say developing pharmaceuticals. Now they can have real viable marketing information based on prescriptions. Not to mention the external prescription system in drug stores that don’t have the security systems of a national chain.

Unlikely, but still possible

These last few are out there a little further, and so they’re less likely to happen from some individual seeking out someone, but a larger system looking for information might be the right kind of buyer. Buyers might include foreign governments, political parties, lobbying firms, stock brokerage firms, pharmaceutical companies, and multinational banks.

As @Dr_Grinch suggested on Twitter, political embarrassment could potentially force a person out of public office or keep them from running again or winning a political race. (beat me to it Grinch)

Blackmail with sensitive information could allow someone an insight into a hidden realm, so insider-trading insights for people who blackmail politicians who already legally engage in insider trading.

While something like herpes might not necessarily be that bad to most people (publicly), finding a Supreme Court Justice or Congressional representative who has cancer markers or a bad heart could be pretty serious for interested parties.

Targeting of a specific patient for murder or to get them out of office.

When someone has a medical condition, let’s say this person is a high value target, something like a heart condition might be a good cover up in the event of unforeseen catastrophic loss. If a country external to the breach had intended to take out a target, a medical breach might give them inside information as to an appropriate means of cover-up. “Heart attack? Seems plausible based on their medical history.”

Stalking / Espionage

Medical information could be used for locating a specific patient who is no longer residing at their primary residence. This information could be used to find patterns of when the person will be out of the area for a localized attack. Typical doctors appointments on Tuesday, good time to bug the house or rob the place. Need a list of places to setup illicit operations? Find empty houses.

Market for locating individuals

Also all of this information in medical systems is much more thorough since people need contact information in the event of emergency. This type of information may be helpful to agencies that try and track people down as well. Bob is off of the grid, but Alice lists Bob as an emergency contact. Charlie needs to find Bob for a client and buys the information.

Sorry, maybe I went a little overboard but if I can think of these things, I'm sure other people have likely already beat me to the punch.