Page 18 - index
P. 18
example. Nevertheless, most of your technical security requirements should be the same. You
want to authenticate devices, you want to kick unauthorized devices off the network, you want
to alert appropriate administrators when something goes awry, you want to configure your
devices according to organizational standards, and so on.
Be Careful With BYOD. If you were to follow the more advanced guidance in this Control, you’d
be spending resources to register BYOD devices and scan them to conned to the corporate
network. Given privacy and civil liberty concerns that employees will undoubtedly have when it
comes to BYOD, you’re probably better off having a solid policy in place for VPN access and
standing up a segregated “guest” network the BYOD’ers can use at the office.
Areas for Improvement
Wireless Is Not Special. Please don’t treat wireless as a special set of requirements. The Control
Framework should be concerned with devices and ensuring that specific security properties have
been considered for a variety of contexts. I have no problem with specific technology
recommendations to meet authentication or confidentiality or integrity, for example (802.1x,
AES, SHA-2, and so on). What I really don’t like to see is a type of device treated as “special.” As
I said in the key takeaways, a wireless device is just another device and we have a need to ensure
operating the device is done so with specific security properties intact. Specific mechanisms
may differ, but I don’t see a reason to treat wireless devices as separate from other devices.
Consolidate. There were several requirements that seemed to be repeats or possessing nuanced
differences. I would prefer to see these requirements cleaned up. Here, I had to look between
them and determine for myself what the differences were. Why not just be crystal clear right up
front? This is really a problem with prose Control Frameworks (is there another kind?) in
general.
For more details on this Control - including a numbered list containing each requirement, its description,
and my notes pertaining to the requirements – refer to the full analysis here.
Data Recovery Capabilities
In a Nutshell:
Be aware of process dependency. The case in point is in requirement 6, which implies that your
incident response team ought to be trained in backup and recovery. It makes some sense, but
this is an example of a character flaw I see across most frameworks: They merely allude to some
of the most important relationships between your controls and your business.
Encrypt wisely. This Control recommends encryption of backup data in transit and when stored
offsite. The devil in these details is key management, which is something that might be
mentioned by some Control Frameworks, but is a subject about which most steer clear. If you’re
doing encryption on your backups, be sure you’re generating keys for the right purpose – long-
lived confidentiality and integrity. NIST has some documentation (PDF) you can read through on
18 Cyber Warnings E-Magazine – August 2013 Edition
Copyright © Cyber Defense Magazine, All rights reserved worldwide
