Why You Need to Hack Yourself
Why You Need to Hack Yourself by Mendix
You need to do your best to break into your own systems. Here’s the biggest reason: If you don’t, they will.
Hacking yourself is a policy enforcement and audit step that all CIOs need to build into their organizations’ DNA. It proves that that your guards are actually up, all security tasks are actually completed, and that best practices and procedures are adhered to. This security measure is part of the quality feedback loop IT departments need to ensure asset and personnel safety. Here’s a checklist of the IT systems and software for which you should consider penetration testing.
Someone is hacking you now, as you read this. Bots regularly knock on your company’s virtual doors. Your doors shouldn’t answer. But some will. Bots are diligent. You need to be, too – at protecting the enterprise.
The devices in your domain are probed and assaulted. There are tools, techniques, and policies that can keep your security intact and keep your organization fit. It takes diligence and tenacity to cover all of the bases, however, as several trends push the limits of any IT department.
There are specific areas to pay attention to, each with implications. The places to hack aren’t unlimited, but they’ve taken on new classifications: user devices (including tablets, smartphones, laptops, desktop systems, kiosks) and any hardware device in your entire back-end infrastructure (including every router or device with a processor in it). Classify these as hardware infrastructure devices, right down to your Wi-Fi access points.
The turf now encompassed by CIOs and IT management staff has expanded into new regions. The “bring your own device” (BYOD) phenomenon is just the latest in the list of potential headaches. Telephony – especially VoIP and VoIP gateways to landline telephony – are new items on the list. Items can be internally located, in the old-fashioned sense, or may be parts of mobility or public/private cloud efforts. In some cases, the actual location of a controlled device is not only unknown, but irrelevant.
A second classification of hacking and means of attack on your assets are applications. Application stacks now consist of bare-metal hypervisors, the control software used to start and stop virtual machines (usually management applications), virtual machines (VMs) – consisting of operating system and operating systems infrastructure/management software – and applications running on VMs.
Each of the devices or platforms in Table 1 represents an opportunity for hacking yourself. Penetration testers, also known as pentesters, use a variety of techniques (both appropriate and sometimes inappropriate) to check devices. Ensuring that updates, patches, and fixes have been applied is usually job number 1, and is also the task that’s toughest because it constitutes the grunt work of IT daily practices.
|Device/Platform||Typical Attacks and Problems||Audit Frequency||Check Applied Updates From|
|Routers||Password attack; port mirroring or sniffing or mayhem||Q||Vendor-Firmware; password strength test and change|
|DNS servers||Poisoning or denial from unauthorized updates||Q||Vendor-Firmware/Software U/P/F|
|SANs/NAS devices/tape devices/disk farms||Unauthorized LUN/NAS/ access; unauthorized access from management software or backplane access; data theft or destruction or DoS||Q||Vendor-Firmware/Software|
|WiFi access points||Password cracks or pre-shared key token thefts permitting unauthorized guest access or DoS||M||Vendor-Firmware/Software U/P/F; key strength test; ACL (access control list) checks; management checks|
|Infrastructure servers||BIOS or UEFI weak authentication; management software cracks||M||Vendor-Firmware/Software U/P/F; key strength test; ACL (access control list) check; management app password checks|
|VM hypervisors||Password cracks then DoS||M||Vendor-Software U/P/F; key strength test; ACL (access control list) check|
|Server operating systems||Malware via viruses and infected apps; network policy issues||DRT||Vendor-Software U/P/F; key strength test; ACL (access control list) check, system logs|
|Server applications||Content infection||D RT||Content examination; application stress testing; pen testing; application release verifications|
|DesktopsNotebooksKiosks||Malware via viruses, infected apps, network policy issues||D RT||OS vendor U/P/F; policy controls via management software; multifactor authentication|
|Smartphones and tablets||Unauthorized access; malware||W||OS and carrier vendor U/P/F; policy controls via management software; ACL checks; multifactor authentication and mobile device management policy controls|
|Data center/NOC||Unauthorized access leading to miscellaneous mayhem||R||Break into your own NOC. Through the ceiling, walking in behind people, whatever. See who is challenged, and who isn’t. Wear a suit and tie or formal attire.|
|Phone system||Hacks into voice mail or Interactive Voice Response systems, and/or SIP gateways and trunks (phone fraud)||R||Platform vendor U/P/F; policy controls, and password stress tests|
|Satellite systems||Physical access for DoS problems; access to gateway equipment||Q||Check physical access; check access to gateway and head-end equipment (varies with systems)|
|Firewalls/Intruder Detection Systems||Improper configurations allow easy penetration||R||OS and platform vendor U/P/F; policy controls via management software; multifactor authentication checks; password life checks|
|Client Applications||Misconfiguration or malware infections||W||App vendor U/P/F; policy controls via management software; multifactor authentication; password controls where applicable|
|Printers and scanners||Misconfiguration mayhem, or hard drives storing sensitive data||M||Check especially that hard drives in disposed printers are physically destroyed and that the hard drives auto-delete jobs after completion|
|Cable plant/IDF||Undesired cabling access for password sniffers||Q||Periodic cabling audits can reveal undesired or rogue access|
|Tape vaults||Unauthorized access||Q||Check ACLs; or if offsite, check inventory and personnel authorization lists|
|UPS||Unauthorized access leading to DoS or mayhem||Q||Vendor/Platform U/P/F|
|Point of Sale||Unauthorized; shrinkage; fraud||R||Vendor/Platform U/P/F; password lengths and random frequency of changes|
|Surveillance Systems||Manipulation, usually for fraudulent purposes (shrinkage)||R||Vendor/Platform U/P/F; password lengths and random frequency of changes; random recording integrity|
|Vendor & SaaS Links||Unauthorized or unaudited access; fraud||R||Varies; check password integrity and audit|
Q = Quarterly
R = Randomly
RT = Realtime, meaning via flow controls
W = Weekly
D = Daily
ACL = Access Control Lists
U/P/F = Updates/Patches/Fixes
DoS = Denial of Service (unintended outage)
Every day, your logs are filling up with information. There is no Internet address on earth that isn’t probed at least several times daily. Fat targets with lots of public-side Internet presence are pounded at each address every few seconds. Update/patch/fix levels are captured in most logs, and if they’re not systematically kept by the device or platform, you should keep logs as patches and updates are applied, as a best practice. The logs should be available, up to date, and have traceability to a human, or to an application controlled by a human in your organization.
When to Contract
Pentesters use automated processes to attempt to crack open your organization. Some processes are very clever, and the penetration testers should supply an explanations of what they did, why it worked, and the remediation and policy efforts you should apply to bring a system back to an appropriate level.
Most pentest hacking success, but not all, comes when they try tricks to crack open your system that are well-known, which someone in your organization forgot to patch, update, reconfigure, or (even if they did those things) retest. But you still need to document that the levels of checking are frequently sufficient. My suggestions are based only on my 30 years in the computer industry.
If your organization is small, you may not have the ability or the desire to perform your own updates. Perhaps you’re busy doing other things. Someone, however, must perform these tasks, so for now, I assume that you contract the task to a security specialist. In such cases, the contractors are charged with the responsibility of doing the maintenance work, which must be done regularly, sometimes immediately. If the contractor hasn’t sufficient liability for the damages you might incur by their sloth, then your exposure to business failure might be even higher than you imagined.
Contractors can be very busy and they forget important things, too, even the most diligent among them. That’s because there are so many possible failure points. Even with automated tools, lapses can expose your organization to the endless commonplace vulnerabilities.
Contractor laxness is still laxness, however, and your own hacking efforts should be done in such a way as to vet their work, whether you contract pentesters or do the work on your own as an internal initiative.
In my opinion, there is no such thing as a secure perimeter in your organization. Firewalls only keep the children out and away from your assets. Each device and platform requires appropriate protection, and can be an entrance point to hack, crack, or attack other assets you’ve deployed.
Audit the Auditors
Contractors can do the grunt work of maintenance well, but an auditing process needs to be established and periodically hacked to ensure that the details are real, and not forged. Appropriate documentation helps, but nothing is as satisfying as a professional hack (I mean: audit) job. No professionals will object to a rational audit of their work.
Should you decide to decline the opportunity to hack or audit yourself, don’t drop us a note. We’ll see the headline. Remember, you’re getting hacked as you read this.