Research

As we dive back into Firewall Management Essentials, let’s revisit some of the high points from our Introduction: The firewalls run on a set of rules that basically define what ports, protocols, networks, users, and increasingly applications, can do on your network. And just like a closet in your house, if you don’t spend time sorting through old stuff it can become a disorganized mess, with a bunch of things you haven’t used in years and don’t need any more. The problem is that, like your closet, this issue just gets worse if you put off addressing the issue. And it’s not like rule bases are static. You have new requests coming in to open this port or allow that group of users to do something new or different pretty much every day. The situation can get out of control quickly, especially as you increase the number of devices in use. So first we will dig into building a consistent workflow to manage the change process. This process is important for numerous reasons: Accuracy: If you make an incorrect change or have rules which conflict with other rules you can add significant attack surface to your environment. So it is essential to ensure you make the proper changes, correctly. Authorization: It is difficult for many security admins to say no, especially to persuasive business and technology leaders who ‘need’ their stuff done now. So a consistent and fair authorization process eliminates bullying and other shenanigans folks use to get what they want. Verification: Was the change made correctly? Are you sure? The ability to verify the change was correct and successful is important, especially for auditing. Audit trail: Speaking of audit, making sure every change is documented, with details of the requestor and approver, is helpful both when preparing for an audit and for ensuring the audit’s outcome is positive. Network Security Operations A few years ago we tackled building a huge and granular process map for network security operations as part of our Network Security Operations Quant research. One of the functions we explicitly described was managing firewalls. Check out the detailed process map: This can be a bit ponderous for many organizations, and isn’t necessarily intended to be implemented in its entirety. But it illustrates what is involved in managing these devices. To ensure you understand how we define some of these terms, here is a brief description of each step from that report. Policy, Rule, and Signature Management In this phase we manage the content that underlies the network security devices. This includes attack signatures and the policies & rules that control response to an attack. Policy Review: Given the number of monitoring and blocking policies available on network devices, it is important to keep rules (policies) current. Keep in mind the severe performance hit (and false positive issues) of deploying too many policies on a device. It is a best practice to review network security device policies and prune rules that are obsolete, duplicative, overly exposed, prone to false positives, or otherwise unneeded. Policy review triggers include signature updates, service requests (new application support, etc.), external advisories (to block a certain attack vector or work around a missing patch, etc.), and policy updates resulting from the operational management of the device (change management process described below). Define/Update Policies & Rules: This involves defining the depth and breadth of the network security device policies, including the actions (block, alert, log, etc.) taken by the device if an attack is detected – whether via rule violation, signature trigger, or another method. Note that as the capabilities of network security devices continue to expand, a variety of additional detection mechanisms come into play. They include increasing visibility into application traffic and identity stores. Time-limited policies may also be deployed to activate or deactivate short-term policies. Logging, alerting, and reporting policies are defined in this step. Here it is important to consider the hierarchy of policies that will be implemented on devices. You will have organizational policies at the highest level, applying to all devices, which may be supplemented or supplanted by business unit or geographic policies. Those highest-level policies feed into the policies and/or rules implemented at a location, which then filter down to the rules and signatures implemented on a specific device. The hierarchy of policy inheritance can dramatically increase or decrease complexity of rules and behaviors. Initial policy deployment should include a Q/A process to ensure none of the rules impacts the ability of critical applications to communicate either internally or externally. Document Policies and Rules: As the planning stage is an ongoing process, documentation is important for operational and compliance reasons. This step lists and details the policies and rules in use on the device according to the associated operational standards, guidelines, and requirements. Change Management In this phase rule & signature additions, changes, updates, and deletions are handled. Process Change Request and Authorize: Based on either a signature or policy change within the Content Management process, a change to the network security device(s) is requested. Authorization requires both ensuring the requestor is allowed to request the change, and the change’s relative priority to select an appropriate change window. The change’s priority is based on the nature of the signature/policy update and risk of the relevant attack. Then build out a deployment schedule based on priority, scheduled maintenance windows, and other factors. This usually involves the participation of multiple stakeholders – ranging from application, network, and system owners to business unit representatives if downtime or changes to application use models is anticipated. Test and Approve: This step requires you to develop test criteria, perform any required testing, analyze the results, and approve the signature/rule change for release once it meets your requirements. Testing should include signature installation, operation, and performance impact on the device as a result of the change. Changes may be implemented in ‘log-only’ mode to observe their impact before committing to blocking mode in production. With an understanding of the impact of the change(s), the request is either approved or denied. Obviously approvals may be required from

I had a really great Friday Summary planned. I was going to go all in-depth and metaphysical on something really important, with a full-on “and knowing is half the battle” conclusion at the end, tying it back to security and making you reevaluate your life. That was before my 6-month-old decided to go to bed after 11pm, then wake up at 3am, and not go back to sleep until 5:15am. Followed by my 4.5-year-old waking me up at 6am because, although she knew it was too early, I forgot to put the iPad that she is allowed to watch until it’s time to wake us up in her room. Then there was the cat. That f***ing cat. (It was my turn to take the baby… he had already wrecked my wife the nights before). So someone is reevaluating their life, but it isn’t you. Instead, I’m going to emulate Adrian: here is my stream of consciousness… Residential alarm companies don’t really like hackers/tinkerers. I have some extensive home automation and I want to pull alerts out of my alarm panel (without enabling control) to trigger certain things and use the sensors. The phone calls tend not to go well. They all have home automation packages they will gladly sell me, and usually after the third time I tell them I have thousands of dollars and tons of custom programming of my own system they finally get it. None of them want to let you access the panel you pay for because they are legitimately worried about false alarms. Can’t really blame them – I wouldn’t trust me either. I finally added some security cameras, mostly to watch the kids outside in the play pool when I have to run inside for my morning… constitutional. I’d like to put some in the play areas but I don’t like how intrusive they look. Need to figure that out. There is a bobcat in our neighborhood. It’s living in the yard of a house that has been effectively abandoned for 3 years because no one seems to know who actually owns or is responsible for it. The bank would sure like the cash, but doesn’t want to deal with maintenance. I smell one of those improperly handled mortgage paperwork situations. The bobcat has cubs and seems quite content to bounce around our backyards. Many neighbors are scared of it, despite, you know, scientific evidence. I mentioned on our community forum that their kids should be safe unless they leash the babies to a stake out in a backyard – that may not work out well. A bunch of neighbors would also like to gate our community due to a mild uptick in break-ins (the other reason for the alarm and camera updates). That would involve about 50 unmanned gates for 900 homes and 6,752 landscapers with keys, judging from the 24/7 blower noises around here. Seriously, we would have to give gate codes to easily over 10K people over the course of the first year. Then there is the maintenance, and if you gate a community you need to take over street maintenance. And there is no evidence that unmanned gates reduce crime. I live with a lot of very scared upper-middle-class people. Other people want to slather cameras all over our community. They don’t understand that no one watches them. Someone thought we would have a control center like a casino or something with security calling in drone strikes for suspicious vehicles. (I consider them a mild deterrent at best, and mostly useful for me to keep an eye on the kids when I need to take my morning constitutional). I mean cameras are mild deterrents – a few drone strikes would probably be pretty effective. Me? I think for a fraction of the long-term cost of either option we could hire additional security and off-duty police patrols. Incident response and active defense, baby! My 4.5-year-old and her best friend have decided which boys they are going to marry. In related news, I will be shopping for a gun safe this weekend. The new Lego Mindstorms EV3 is amazing. I’m a long-time fan of Lego robots, and this one is far more accessible to my young kids due to the ball shooter and iPhone/iPad control. I still need to do all the building and programming, but I’m working on getting them to tell me what they want it to do and break that down into discrete steps. They want me to build an “evil robot” so they can put on their super hero clothes and battle it. The 4.5-year-old has a nice Captain America shield (she was pissed the first time she threw it, because it didn’t come back), and the 3-year-old has a cool Fisher Price Spider-Man web shooter thing. Both girls, both started on super hero kicks without my influence, and both are totally awesome. That’s all I got. Go buy Legos, watch out for bobcats, and don’t get involved in your community security program unless you want to realize how nice our infosec world is in comparison. Seriously. One last note – good luck to everyone in Boulder. It’s very hard to watch the floods from the outside, but still a hell of a lot easier than what you all are going through. Stay safe! On to the Summary. To be honest, due to the lack of sleep and my family walking in the door, it’s be a bit light this week… On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich presenting on cloud encryption next week. Rich wrote two articles on Apple’s Touch ID fingerprint sensor. You can read them at Macworld and TidBITS. They were both referenced by a ton of sites. Rich also quoted on Touch ID at the Wall Street Journal. Cloud IAM webcast next week: Check it out! Adrian’s DR post on PII and Entitlement Management. Another DR piece from Mike on “Talking Threats with Senior Management”. Mike’s latest DR column on the million bot network. Mike quoted