Product security in the wake of Sony
Product security in the wake of Sony
The Sony security breach has been all over the news lately, and in its wake we’ve been getting a number of security-related questions from our customers. Although there’s been no implication of wireless networks in the Sony breach, Aruba customers are justifiably worried about technology that can link attackers in the parking lot (“car park” for our non-American friends) with their internal LAN. Obviously, no IT product can make the claim of 100% security (and anyone who does should be kicked out the door) but let me at least try to explain how we approach product security at Aruba. Here is a sample of some of the questions we have received:
Is the software on your controllers secure?
100% secure! OK, maybe my Midwest sense of humor isn’t appropriate right about now. But seriously, it’s as secure as we know how to make it. We put our engineers through secure coding courses. We do extensive code reviews/audits where multiple software engineers get in a room together and look over each other’s code. We use static analysis tools to automatically scan the source code looking for potential problems like unbounded memory access. We use fuzz testers to abuse external inputs, looking for crashes. In places where we use open-source software, we monitor those packages for reports of vulnerabilities, and we patch against them. Finally, every software release is scanned by a number of different commercial vulnerability scanners to look for known problems.
That’s not always enough – and if you monitor our security advisories, you know we have disclosed vulnerabilities in ArubaOS and other products in the past. So over the past few years, we have really ramped up external testing/auditing of our software. We certify our software under FIPS 140-2 and Common Criteria on a regular basis. We’ve also undertaken certification in the UK under the Commercial Product Assurance (CPA) program and hope to complete that in early 2015. And we have paid for a number of different private security audits/penetration tests with various security firms, hoping to get some targeted focus on specific areas. Still – we can do more. I’m happy to announce today that beginning in November, Aruba signed on with Bugcrowd to provide a managed bug bounty program for security vulnerabilities. This gives us access to the vast scale of “crowd-sourced” security research, while Bugcrowd makes it easy for us to pay researchers for their discoveries. We’ve already seen some positive results from the program (no, nothing serious, but certainly areas where we could improve.) Right now the Aruba program with Bugcrowd is private, open only to their top 100 researchers, but next year we’re hoping to open it up to the general public.
Do Aruba products take remediation actions if they detect something?
Yes and no – it really depends on which products you have deployed. The Policy Enforcement Firewall (PEF) within ArubaOS can be used to apply role-based access control. If your company is (for example) a movie production studio, there’s no reason that the receiving clerk in the warehouse should be given access to the server that holds scripts for upcoming productions. PEF can be used to segment network access based on the role of the user or device. But detecting unusual activity or security vulnerabilities originating from wireless client devices? That’s really the job for an intrusion detection system and an endpoint posture assessment system, respectively. For IDS and advanced firewall services, I highly recommend taking a look at our partnership with Palo Alto Networks. For endpoint posture assessment, our own ClearPass Policy Manager includes OnGuard, which is tightly integrated with the network infrastructure so that non-compliant systems can be quarantined and remediated. By the way, did you see the latest news about ClearPass and OnGuard? We're not the only people who think it's a great product.
You are using open-source software on your products. Is it secure?
We treat the open-source software the same as we treat code we write ourselves – subjecting it to the same testing. “Great,” you say, “so why didn’t you guys detect HeartBleed?” That’s a very good question, and one that the entire IT industry is still trying to answer. The reality is that as an industry, we’re good at testing for yesterday’s threats. If we were equally good at testing for the threats we haven’t yet discovered, we could get rid of all vulnerabilities overnight. What I can tell you is that since HeartBleed, the open-source community has really stepped it up a notch in terms of looking for security vulnerabilities, and a number of our own security advisories this year have actually come from an open-source component within our product.
The astute reader will recognize that products like ClearPass and AirWave are built on top of a Linux operating system. Some of you have even helpfully emailed the Aruba SIRT with long lists of vulnerabilities on AirWave, picked up by your vulnerability scanner. It’s important to recognize that with open-source software, we try to minimize the attack surface as much as possible. Yes, we use OpenSSH, but we don’t enable every possible option within that software. AirWave, as an application, makes use of certain OS-provided functions, and certain functions provided by open-source software packages, but we tightly control that usage and we focus our security testing on the actual attack surface. So when the “Shellshock” vulnerability came out earlier this year, it was clear that the version of “bash” installed on AirWave servers was vulnerable (they all were). However, AirWave never actually called the bash shell in a way that someone could exploit the vulnerability over the network. We are monitoring daily for vulnerability reports affecting open-source software that we use – each time we get one, an assessment is done to determine whether or not the vulnerability can be exploited given how we have deployed the package. If it’s exploitable, we will issue a security advisory giving instructions for remediation.
How can we ensure certificates are valid?
This is a rather ambiguous question, but I’ll try to address it in different ways:
- Each Aruba hardware product (controllers and APs) ships from the factory with an Aruba-issued X.509 certificate embedded within it. This certificate is used for authentication between Aruba components. The private key for this certificate is stored in a Trusted Platform Module (TPM), which is a tamper-resistant chip that is part of the main board of each Aruba product. The private key is generated securely inside the TPM – it is never available externally. Assuming the TPM itself is secure (we think it is), there is a 0% chance that someone has the private key belonging to your Aruba hardware product. There is only one copy of the private key, and it is locked inside the hardware. With that said, we still need to consider the security of the PKI that enables these certificates to be produced. There’s only so much I can say here – we consider the specific configuration of this PKI to be proprietary information – but what I can say is that we follow industry best practices on PKI security and have gone to great lengths to ensure that the system cannot be compromised. Those measures involve the use of an offline root CA, hardware security modules (and as a side note – wow, HSMs are expensive), and strong physical security controls. There are no guarantees, but we think we’ve done as much as we can to keep this system safe.
- Each Aruba software release is digitally signed, such that if someone were to modify ArubaOS images on our support site, the controller would reject that software as invalid. The signing keys are treated with the same protections afforded to our manufacturing PKI, and usage of the signing keys is audited.
- Certificates which you yourself load onto Aruba products – well, here I can’t help you as much. I have seen some very good internal PKI practices, and some very sloppy practices. If you’re following good practice (and this generally means keeping private keys secure) then as long as you have good physical security protecting your Aruba equipment, those certificates are safe. If you have bad physical security – well, I suspect the intruders are going to go straight for the servers rather than fool with the Wi-Fi equipment, but physical compromise of a mobility controller does give an attacker the ability to change configuration, upload new certificates, etc.
- Certificates which are used for Wi-Fi client authentication should be checked for revocation. I don’t see this happening enough in practice, but ArubaOS and ClearPass both support Online Certificate Status Protocol (OCSP) which should be consulted during each authentication process to determine if a certificate is still valid.
If you’re the person who asked this question, and I didn’t address it adequately, please leave a comment and I’ll take another shot at it.
Is Wi-Fi secure, in general?
I hate to bring up the NSA, given their ranking in the popularity contest over the last few years, but they have approved the use of Wi-Fi to transmit classified information in government and military networks. Security requirements for classified networks are more stringent than anything I’ve seen in all but a couple enterprise networks. Those guys are reportedly pretty good at breaking into networks – if they think Wi-Fi is secure enough for their own use, I am going to trust that assessment. That being said – you can configure a Wi-Fi network in a secure manner, and you can configure it in a non-secure manner, so network design is important. See the next question.
How should we configure our Wi-Fi network for maximum security?
I could go on for pages. In fact, I have already. Have a look at our Security Guides – right now, we have produced these for ArubaOS and for ClearPass – other products are in the works.
Please leave comments if you have additional questions – I’ll do my best to answer.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.