Effective security professionals are great innovators by nature. Continually forced to do more with less, security managers create new ideas in an ever-changing industry.
However, in the security field, the ways in which value is created are changing all the time. So are the strategies required to protect that value. For security managers, the challenge is to be the type of leader who understands how the value creation process is changing, and to then lead the security department so that it best leverages its value for success.
This type of leadership works best through collaboration. Kevin Kruse, the founder and CEO of LEADx.org, describes leadership as "a process of social influence which maximizes the efforts of others towards the achievement of a goal." Undoubtedly, the process of social influence is key for security leaders, who typically do not have the authority to tell everyone in the organization what to do and have them comply.
Moreover, the environment that today's security manager is trying to lead in is filled with rapid change. These changes include massive shifts in technology in both software and hardware, as well as vast changes in the compliance landscape. For security leaders who are not experts in cybersecurity, such as physical security managers, these developments can be daunting to understand and get a handle on. But avoiding them and staying completely within one's silo or area of expertise can make collaboration difficult, and it will lessen the likelihood of effective social influence.
On the other hand, physical security managers who make the effort to gain an understanding of the effects of these technology and compliance changes, and how their effects can be harnessed to bolster the security of the overall enterprise, can then build bridges between different sections of the security world. These bridges break down silos, and they increase the social influence of the security manager and the chances of successful collaboration.
With that in mind, this article will discuss a few current technology and compliance developments, and the impact they might have on enterprise security.
DevOps, a software engineering culture and practice aimed at unifying software development (Dev) and software operation (Ops), is changing the way that digital experiences are being created in software.
One of the main characteristics of the DevOps movement is a push to automate and monitor all steps of software construction, including integration, testing, and deployment. As a result, some of the aims of DevOps are shorter development cycles, increased deployment frequency, and releases that are closely aligned with business objectives.
DevOps specialists John Willis and Damon Edwards have used four terms to define the movement—culture, automation, measurement, and sharing. Under this approach, which is radically different from the traditional one, software is delivered continuously. Teams that had previously worked in silos come together to achieve common goals. As soon as someone comes up with an idea for a new digital experience, a cross-functional team can quickly turn it into reality.
The DevOps movement is catching on. Currently, 27 percent of surveyed organizations are using a DevOps methodology, according to the latest version of the annual report, The State of DevOps, published by software services company Puppet in 2017. Clearly, the use of DevOps is on the rise, and it is something that security managers should be up to speed on.
Compare the execution of some security functions in a DevOps versus a pre-DevOps world. In the pre-DevOps world, organizations built technologies in private data centers, and security professionals focused on protecting the perimeter of those centers. Similarly, the traditional brand of waterfall software development (where progress flows in only one direction—down—like a waterfall) takes time, enough time for lengthy cybersecurity reviews and approvals to take place. During this painstaking process, there is a strong focus on preventing breaches from occurring.
In the DevOps world, use of cloud infrastructure and automation transforms technology infrastructure so that it is now managed as software via application programming interfaces (APIs). The focus is on application and API security, instead of the traditional focus on host and network security. In this world, almost every software company is both a vendor to other software companies and a customer.
The connected ecosystem of the DevOps world pushes enterprise security away from its previous commonly assumed role as a cost center and pushes it toward the clear position of business driver. It is explicitly requested during the sales process—usually in the form of a vendor security questionnaire. A DevOps world assumes that security incidents are happening all the time and acts accordingly.
But security managers should know that buying a DevOps product can be different from buying a more traditional enterprise IT product that is installed in a private data center.
The purchase of the traditional product often meant building a long-term, old-school relationship that required significant investment by both parties. This eventually built trust, if both parties acted in good faith.
In contrast, Cloud, Security as a Service (SaaS), and other DevOps solutions have been described as "easy come, easy go," and they are often acquired in a low-friction transaction environment, over a shorter time frame. The quality, security, and regulatory compliance of these solutions must be expressed to the security manager in a more explicit way.
To illustrate, consider the following example. A DevOps vendor has begun to close a deal with its first big enterprise client. Now that the enterprise client has decided that it is interested in purchasing the DevOps vendor's product, it's time for the enterprise client's security team to get involved (just as the legal and purchasing departments will get involved regarding the contract and payment components of the transaction).
The enterprise security team sends the DevOps vendor a security questionnaire, which typically contains many questions. In some cases, receiving these types of security questionnaires can be intimidating to a DevOps vendor. In other cases, it can inspire the vendor to help drive and continue to mature the security program.
But no matter what the DevOps vendor's initial reaction is, the role of security has been transformed. It's an obvious and crucial part of completing the sale, from the point of view of both the vendor and the enterprise organization. Thus, the perception of security here is as an explicit business driver, which was not necessarily the case in the traditional IT product world.
Of course, physical security managers do not need to become technical experts on software development. However, understanding how DevOps changes the transaction process and the perception of security could become valuable knowledge for security managers of all types, including physical security managers.
Moving forward, the potential commercial advantages of the DevOps approach will likely make the software development trend an attractive one for many more organizations. Physical security managers who can meet this trend with a basic understanding of its potential impact will be well-positioned to collaborate with technology managers, for the benefit of the enterprise's overall security.
In a recent survey by Business Insider Intelligence, executives were asked various questions about the Internet of Things (IoT). Security was found to be one of the most consistent concerns, chosen by 39 percent of survey respondents, well ahead of other concerns like questionable ROI, lack of a use case, and price. The security concern, in a nutshell, is that increased adoption of IoT technology may expose organizations to new, more prevalent hacks.
In the past few years, security experts have executed, for demonstration purposes, alarming hacks on connected vehicles (2015), sniper rifles (2015), and cardiac devices (2017). Technically, many of the security vulnerabilities exploited in these hacks are similar to those of more conventional technologies such as servers, but the methods for detecting and addressing vulnerabilities in a connected web of smaller and less capable devices can be much more complex.
"Paradoxically, the very principle that makes the IoT so powerful—the ability to share data with everyone and everything—creates a huge cybersecurity threat," write Christopher J. Rezendes and W. David Stephenson in a recent Harvard Business Review article, "Cyber Security in the Internet of Things." As with any software product, the best approach for reducing the risk of software-connected vehicles and other types of systems is to assess and monitor security during the product development lifecycle.
Security managers should evaluate IoT systems with misuse and abuse cases in mind, considering how IoT features might be unintentionally misused or intentionally abused. In this way, the approach to reviewing an IoT system is not much different from the approach that has been commonly used for years to assess software security.
The methodology is called threat modeling, and this can be done either by an internal security team or outsourced to a third party that specializes in this type of analysis. The first step in creating a threat model is to identify the assets, security controls, threat agents, and threats within the system. The next step is to estimate the likelihood and impact of each threat within the system. Then, an associated mitigation plan for each potential flaw is developed.
It is also critical for security managers to ensure that security fundamentals remain in place when working with the IoT environment. One of the founding principles of IoT security is that access should always be shut down where it's not necessary.
In addition, because IoT devices are primarily consumer facing, it's also important for security leaders to ensure that consumers are aware of and actively implementing cybersecurity basics such as the use of strong passwords and software updates.
Like DevOps, IoT systems are very likely to become more widespread in the next few years. Familiarity with the threat modeling process and other means of evaluation and sustaining bedrock principles will be valuable tools for security leaders, including physical security specialists, to possess. In addition, managers who supervise enterprise security risk management (ESRM) programs will find that IoT threat models often complement the overall ESRM program. This is because both take the same approach of using risk management principles to identify potential threats and their likelihood, and then strategically allocating resources to fight the threats.
For the past decade and a half, security professionals have been navigating a changing regulatory environment. To date, many regulatory compliance frameworks have been applicable to only one specific industry. Payment Card Industry (PCI) standards apply to financial services, the Health Insurance Portability and Accountability Act (HIPAA) applies to the medical field, and the Sarbanes–Oxley Act (SOX) applies to public companies.
Additionally, each set of rules and regulations has different enforcement mechanisms. PCI, for example, applies differently to various tiers of an organization, and the actual fines that have been paid by noncompliant organizations have been fairly limited.
But all of that changes with the General Data Protection Regulation (GDPR). GDPR enforcement officially began in May 2018, and it applies to organizations located within the European Union (EU) and to organizations located outside of the EU that offer goods or services to, or monitor the behavior of, EU citizens. Organizations that do not comply with GDPR requirements can be fined up to 4 percent of annual global revenue or up to €20 million (roughly $24 million), whichever is greater.
While the focus is on consumer privacy, GDPR has a lot to say about processes and procedures surrounding data breaches, vendor security, and data protection in general. At a high level, the regulation requires organizations to develop a data inventory and continuously track how data is processed, stored, and transferred.
Given this, many proactive security leaders will be developing plans for how to proceed when it comes to either providing vendor services or leveraging a vendor for data processing, storage, or transfer. Many will also develop plans for responding to an incident that takes into consideration what action is required by GDPR in the case of a breach. A physical security manager who has sufficient working knowledge of GDPR can be a valuable asset as a participant in this plan development, and the enterprise at large will benefit from the fact that the plan was a collaborative effort between different security specialists.
For more information, the full GDPR document is available publicly. There are also many guides, runbooks, and "do's and don'ts" online that professionals can review to learn how others are interpreting the information.
Bridging Worlds in Person
DevOps, IoT security, and GDPR compliance are all rapidly changing areas within the overall technology and regulatory landscape, and they all offer opportunities for security managers who are not cybersecurity specialists to build bridges into the worlds of technology and information compliance.
Physical security managers who had educated themselves on the basics of these topics can then learn more when meeting with technology specialists. Such meetings often proceed more smoothly if the physical security manager goes into the meeting with a productive eager-to-learn attitude.
So, when meeting with technology and compliance experts, ask questions and save your demands. Spend twice as much time listening as talking. The more curious you are, the more likely you are to learn something that will benefit you as you put together an approach toward improving overall enterprise security.
Some important questions for a physical security manager to ask a technology manager or engineer might include: What's important to you? What are your top priorities this quarter? What worries do you have about getting your job done? This information can be used to align security goals with technology goals. It can also provide context, and a more accurate answer, for a security manager who is mulling over the question of why security tasks do not seem to receive the time or resource allocations that they should.
A similar approach will also benefit physical security managers who want to build bridges with the organization's business leaders. Before meeting with these leaders, security managers should spend time learning about the business side of the organization. Then, they can dive into specifics during the meeting, using the same types of open-ended questions used with technology leaders.
Astute security leaders know that they cannot approach business and technology teams and order them to work in a certain way. If security managers do not spend time and effort learning about how other specialists work, what their priorities are, and what risks matter to them, trust will be hard to build. When was the last time you listened to the advice of someone you didn't trust?
Caroline Wong, vice president of security strategy at Cobalt.io, has held executive security and management positions at eBay, Symantec, Cigital, and Zynga.