If there were ever a long-running hit TV show about mobile security, it might start with a stentorian voice announcing, “In the world of securing mobile devices, end users are represented by two separate yet equally important groups: The cybersecurity team, which sets mobile security policies, and the mobile operations team, which enforces them. These are their stories.” Dun-Dun…
Kidding aside, as mobile security has grown in importance in recent years, many organizations are struggling with who is responsible for doing the actual security work. Is it the security team, or the operations people? Both have a role to play in protecting mobile devices and the networks that are connected to them.
Why mobile security matters more today
Mobile security is more important to an organization’s overall security posture than it was just a few years ago. This shift is due to a number of factors, most prominently the dramatic shifts in employee behavior and the workplace in general. While mobility was once a luxury reserved for senior executives, today virtually all knowledge workers have the potential to be mobile.
Indeed, mobility is now the norm. In some cases, increased employee mobility is part of a hybrid work arrangement. People are connecting to corporate networks from apartments and coffee shops on personal mobile devices. Even without a dedicated hybrid work program, employees mostly now assume they can work wherever they want, whenever they want, on whatever device they choose.
Virtually all computing devices have become mobile, or have the potential to be mobile. Whether it’s a tablet, smartphone or laptop, these devices are likely to be leaving the main corporate campus—where they will need to be secured at all times.
The assignment of responsibility for security
As the security perimeter moves from the office to the coffee shop, who is in charge of protecting the employee’s endpoint and all the digital assets connected to it? In most companies, it is a mix of organizational units. At the highest level, the board of directors holds responsibility for cybersecurity. Their duty is to protect shareholder assets, which include data and technology. The Chief Information Security Officer (CISO) is deputized by the board to define the necessary security policies and ensure that they are enforced.
Other people and teams are involved, as well. These include the Chief Privacy Officer (CPO), the Chief Compliance Officer (CCO), the Chief Risk Officer (CRO), the Head of Internal Audit and others. The Chief Technology Officer (CTO) or Chief Information Officer (CIO) also have roles to play, though the best practice is to avoid having security reporting into the head of the IT department. This creates a potential conflict, because the CTO’s job performance may be affected by security metrics like the number of breaches of malware-driven downtime.
Such assignments of responsibility and lines of reporting may be necessary for purposes of governance, but they can create tension and uncertainty. For example, if the Chief Privacy Officer insists on implementing privacy policies, but the CTO’s team doesn’t have time to take care of the project, is it still fair to judge the CTO for a privacy failure? Furthermore, policies for security and compliance can be in conflict with one another, e.g., when security mandates encryption of data at rest, but compliance mandates being able to review customer data in real time. It’s hard to do both.
Operationalizing mobile security
The key thing here is that the CTO/CIO is almost always responsible for making security happen on a day to day basis. The other C-suite execs may determine the policies, but the IT department is operationally responsible much of the time. Think about it like this: If an employee’s iPhone gets a virus or can’t reach a VPN, he or she isn’t going to be calling the CCO or CRO to resolve the issue. They’ll call the Help Desk, which is part of IT.
One exception to this rule is the security operations center (SOC), which is responsible for monitoring security and responding to alerts. The SOC team has operational responsibility for enforcing security policy. Otherwise, and especially with regard to mobility, security work is performed by IT people.
The primacy of the IT team in implementing mobile security measures should theoretically give them a voice in the definition of mobile security policies. Not that this always occurs, but a wise practice is to create engagement between security and IT teams to develop coherent, effective and practical mobile security policies that can be monitored and enforced.
Assuming one can get these two groups together, the governing ethos of the collaboration should be that the best kind of security incident to deal with is one that never happens in the first place. Good mobile security policy aims to stop attacks before they reach the endpoint, or just after—before a device can become infected and become a conduit that allows bad actors to breach the entire corporate network.
Another best practice is to think about mobile security across the full lifecycle of mobile technology. Starting with procurement, security and IT teams need to be aware of which products are best aligned with their policies and practices. As an organization acquires mobile technology, the two teams have to define, and then execute policies related to endpoint hardening, threat detection and so forth.
Then, as mobile devices go through their lives, they need to be monitored and patched. This is an IT operations job, usually, but it should be done hand in glove with policy making people. As devices reach end of life, they need to have their data archived and memories wiped, as per policy.
A unified endpoint management (UEM) platform will likely be critical for success in these endeavors. The UEM toolset enables all stakeholders to keep track of devices and policies throughout the lifecycle. The help desk is also a foundational element of mobile security success. IT people who operate the desk have to be aware of mobile security policies and be trained on responding to security incidents involving mobile devices. For example, they may need to know how to initiate an incident response workflow with the SOC, even if the device in question is in a remote location.