Planning Considerations for BYOD and Consumerization of IT (Part 6)

If you would like to read the other parts in this article series please go to :

• Planning Considerations for BYOD and Consumerization of IT (Part 1)
• Planning Considerations for BYOD and Consumerization of IT (Part 2)
• Planning Considerations for BYOD and Consumerization of IT (Part 3)
• Planning Considerations for BYOD and Consumerization of IT (Part 4)
• Planning Considerations for BYOD and Consumerization of IT (Part 5)

Introduction

In the first part of this series on planning considerations for security BYOD and consumerization of IT, we looked at the Bring Your Own Device (BYOD) problem domain and discussed key aspects of planning and design. We finished up the article by looking at the structure of a planning frame work that you can use to guide your planning decisions. In Part 2, we discussed a collection of solution requirements that cuts across all secure BYOD deployments. This encompasses the technical capabilities that are required in all BYOD solutions. In Part 3, we continued our coverage of the BYOD requirements and the history and intent behind them. In Part 4, offered some thoughts about the need for your BYOD strategy to support modern authentication mechanisms. In Part 5, we moved on to the discussion of BYOD compliance with government and industry security and privacy standards.

Why auditing and reporting are important in a regulated business world

You can take every step possible to ensure that the employee-owned devices that access your network are secure and in compliance with the regulatory requirements under which your organization falls, but if you don’t have the documentation to prove it, you may still be in hot water. You get the information for that documentation by auditing, and you preserve that information through reporting.

During my law enforcement years, I taught report writing at the police academy. It wasn’t one of the most exciting classes that recruits had to complete in their journey to earn a badge, but I tried to impress upon them that it was in fact one of the most important. In fact, it comes right after defensive tactics, which could save their lives, because report writing is a skill that could save their careers.

A common saying around the police department is “If it’s not in the report, it didn’t happen.” That’s not true, of course – but that’s the way administration, internal affairs, and the lawyers and courts are going to look at it. And that’s the way the regulatory agencies are going to look at it if you don’t have written documentation that shows that your security mechanisms are in place and effective.

IT pros are lucky, though. Police officers, at least in my day, had to painstakingly print or type their reports detailing the particulars of every incident. Today things have improved somewhat; they have voice recognition/dictation equipment and some aspects of reporting have been automated – but not nearly to the extent that IT reporting is automated.

Compliance auditing and reporting

Attempting to manually gather, organize and report on compliance information is complicated by the fact that such information is often spread across different servers, different IT silos, and stored in different physical locations because only in the largest organizations do you find dedicated departments tasked with ensuring compliance. In most cases, that responsibility is shared by many different people in different parts of the company. Manual processes are very time and personnel intensive (and thus costly) and prone to error. In a BYOD environment, this is even more true because of the number and mobility of the devices that must be shown to be in compliance.

It’s almost mandatory to automate the compliance documentation process. However, the auditing and reporting process must be customizable to fit each organization’s particular situation.

What, when and how to audit

Auditing can be a tricky thing. When considering exactly what to audit, it’s easy to think “the more, the better” – but that’s not necessarily true. Logging of too many events can not only negatively impact the performance of your systems, it can also make it very difficult to find the information you need when you need it.

In considering which objects and events to audit, you have two considerations:

• What information do you need for your own tracking purposes?
• What information do you need for proving compliance?

Any item that doesn’t fall under one of these categories doesn’t need to be audited. This means auditing needs will be different for different organizations, based on how you do business, the type(s) of data you deal with, the level of security you want to implement, and which compliance regulations pertain to your company.

Some basic items to audit for most compliance purposes would include:

• Logon attempts (success and failure), times, durations and related information
• Devices used to access corporate resources
• Device encryption status and health information (anti-virus/anti-malware protection, up to date operating system and application software, and so forth)
• Device features enabled
• Remote lock status
• User actions (files accessed, unsuccessful attempts to access files, modifications and deletions to files/folders, failed attempts to write to or delete files/folders and so forth)
• Methods of access (terminal services/remote desktop, VPN, web services, etc.)
• Administrative actions (users added/removed/disabled, permissions and privilege changes, configuration settings changes, changes to audit settings, etc.)

One thing that complicates the process of auditing for compliance reporting is that you need to be able to relate the objects/events audited to the particular regulatory requirements. For example, HIPAA section 164.308(a)(5)(ii)(c) requires “Procedures for monitoring log-in attempts and reporting discrepancies.” That would map to auditing of successful logon/logoff, failed logon, terminal services/remote desktop logon, VPN logon. Each audit item that you enable should be similarly mapped to the relevant section of the statute or regulation that contains a specific requirement.

DIY or not?

To document your compliance with regulatory requirements for the BYOD devices that connect to your Windows Server network infrastructure, one option is to go through all of the regulations along with your own business-driven requirements and set up auditing yourself using Windows’ built-in auditing capabilities. The auditing feature in Windows has become more sophisticated over the years, with the number of audit policy settings increased with every new iteration of the OS and all auditing integrated into Group Policy.

Enhancements to auditing in Windows Server 2012/2012 R2 have made it easier to reduce the volume of audit information by allowing you to apply audit policies to specific files and users based on attributes and user/device claims. Global Object Access Auditing, combined with claim-based auditing and Dynamic Access Control enables you to apply enforcement to a more precise set of activities. Another important addition was the ability to audit files on removable storage devices.

Documents can be classified, for example as High Business Impact, and access to those documents by users who don’t possess a minimum required security level can be logged, or you can log access or attempted access by users to documents related to projects they aren’t working on. You can find out more about Windows Server 2012/2012 R2’s security auditing and advanced features in the TechNet library.

Audit Collection Service (ACS) in System Center 2012/2012 R2 can be used to collect the information that the audit policy generates, which is stored in the local Security log, and put it into a centralized SQL database. This makes it easier to filter and analyze the events using SQL Server’s analysis and reporting functions. Find out more about ACS here.

SQL Server Reporting Services includes a set of tools that you can use to create very customizable reports from relationship databases, XML and other sources. It was originally released as an add-on to SQL Server 2000 and is included as a part of SQL Server 2008 R2, 2012 and 2014.

The advanced security auditing in the latest versions of Windows Server provides you with a powerful tool, without spending additional money for a third party auditing solution. However, there are many third party solutions available that may fit your needs better. Those who have read my reviews know that one of my favorites in this space is Netwrix Auditor. Netwrix has information on using their product for compliance with some of the most common industry and government regulatory requirements:

http://www.netwrix.com/PCI_Compliance.html

http://www.netwrix.com/SOX_Compliance.html

http://www.netwrix.com/HIPAA_Compliance.html

http://www.netwrix.com/FISMA_Compliance.html

Large companies also offer compliance auditing as part of their systems management software (for example, IBM’s Tivoli Compliance Insight Manager).

Summary

Regulatory compliance is already a major pain point for IT, and BYOD makes it even more complicated because IT has less control over employee-owned devices. A BYOD program is likely to raise a red flag for compliance auditors and cause them to look even more closely at the adequacy of your security efforts. It’s essential that you have proper documentation showing who has logged onto your network, with what devices, when, and what they did while connected.

This wraps up our 6 part series that took you through a process of planning for the most secure way to embrace BYOD and the consumerization of IT in a regulated, compliance-driven business world. I hope it has provided some food for thought and served as a starting point for making the jump to BYOD go more smoothly for your organization.

If you would like to read the other parts in this article series please go to :

• Planning Considerations for BYOD and Consumerization of IT (Part 1)
• Planning Considerations for BYOD and Consumerization of IT (Part 2)
• Planning Considerations for BYOD and Consumerization of IT (Part 3)
• Planning Considerations for BYOD and Consumerization of IT (Part 4)
• Planning Considerations for BYOD and Consumerization of IT (Part 5)