Most organizations have objectives for quality and improvement. Enterprises want employees to continually look for opportunities that fuel effectiveness and strengthen the company. The improvement theme is both a nice to have and a basis to survive, providing a direction to get better and a model for personal behavior and work culture. The basic improvement model is one of common sense, similar to those used in psychology and coaching. It can be teamed with any process reference model.
The improvement model has evolved over time with influences from many thought leaders, good practices and industries, including Dr. Edwards Deming, a key influence with the Plan-Do-Check-Act (PDCA) cycle (preferred over Guess-Do-Pray-Hope); John Kotter with organizational change; international standards such as those from the International Organization for Standardization (ISO), ISO 90001 for Quality, ISO 20000 for IT Service Management, ISO 27001 for IT Security; COBIT, ITIL, the National Institute of Standards and Technology (NIST) and Project Management Body of Knowledge (PMBOK), all of which incorporate or support improvement themes; and, Six Sigma programs, which have an improvement phase and so should you.
How do you do it? You can hire a Six Sigma person or you can do it yourself. It’s not difficult. For most of you, read a book or gain some awareness. ISACA offers a book titled COBIT® 5Implementation in the COBIT product family. While the focus is on implementing governance of enterprise IT, one could add an alternative title: Process Improvement for Management of IT-related Processes.
The book highlights a cycle of phases and component parts, all building on good practices. The 7 phases of the COBIT® 5 Implementation lifecycle include:
What Are the Drivers?
Where Are We Now?
Where Do We Want To Be?
What Needs To Be Done?
How Do We Get There?
Did We Get There?
How Do We Keep the Momentum Going?
Each phase is supported by 3 components: program management (PM), change enablement (CE) and continual improvement (CI). This is a good practice approach.
As an example, the components of the first 3 phases include:
What are the drivers?
CI – Recognize the need to act
CE -Establish a desire to change
PM – Initiate a program
Where we are today?
CI – Assess the current state
CE – Form a team
PM – Define opportunities or challenges
Where do we want to be?
CI – Define the target state
CE – Communicate the desired outcome
PM – Define a roadmap
Each component has suggested or potential key activities, inputs and outputs. Warning: If you miss addressing any of these phases or components, or get overly creative with the order, you might increase the risk of failure. Like software, avoid customization.
Where to Start? Where to start? Pain points and triggers are obvious. To gain a quick win and show how it is done, consider focusing on one process—your favorite process.
The COBIT 5 Implementation book gives you a starting place—allowing you to move forward with confidence on a solid foundation. Think of it as a playbook or recipe. Project managers like the 3 components as they address areas of frequent challenge, such as change enablement. Copy and save this model into your head and project templates.
COBIT 5 Implementation offers all of us consistent context and structure for current or potential activities. It contributes to the success of you and your team. The focus is on people—all of us; up, down and across the organization in any business line.
Editor’s note: John Jasinski holds all ISACA certifications and certificates and teaches COBIT. He is an ISACA member and has been an active volunteer at local and international levels since 2006. COBIT 5 Implementation is available as a free PDF download for ISACA members. The printed hard copy is available from the ISACA bookstore. John suggests you buy a bunch and share them with your team. COBIT is currently celebrating its 20th anniversary. Learn more here.
John Jasinski, CGEIT, CRISC, CISA, CISM, ITIL, Business Process Consultant
1996 had its share of significant events. The first flip phone, the Motorola StarTAC, went on sale. The Czech Republic applied for European Union membership. Australia defeated Sri Lanka 2-0 to win cricket’s World Series Cup. The first version of the Java programming language was released. The massive Internet collaboration “24 Hours in Cyberspace” took place. IBM computer Deep Blue became the first computer to win a game of chess against a reigning (human) chess champion. Excel Communications Inc. became the youngest company ever to join the New York Stock Exchange. Intel released the 200 MHz Pentium chip. And ISACA published the first edition of what was then called Control Objectives for Information and related Technology, or COBIT, as its typography was styled at the time.
Of course, at the time it was released, no one knew it would be just the first of several versions of COBIT. Nor did they foresee that it would undergo continuous evolution to make it ever more relevant and useful to practitioners seeking to control organizational information and the technology that processed, manipulated and stored it. Neither could anyone have anticipated the level of acceptance and use COBIT would achieve, as it was increasingly used—alone or in combination with other frameworks or in-house solutions—in governments and companies large and small worldwide.
COBIT 5: A New Framework for a New World
Since its release, COBIT 5 has been downloaded tens of thousands of times, has been widely discussed on social media, and has been prescribed for use by national governments and municipalities alike. Likewise, the impetus for use of COBIT has evolved from just supporting internal audit to a means of organizing multiple frameworks (including regulatory frameworks) and as a means for connecting overall enterprise objectives to the governance and management of IT assets.
The traditional use of COBIT has been to assist companies with their compliance and assurance needs, but those needs exist outside of just for-profit companies. For example, the government of South Africa has mandated the use of COBIT among municipalities.1 The intent is to exercise proper control over the use of scarce IT resources to ensure delivery of value to those served. Municipalities are expected to use COBIT to align their goals for the use of IT assets with the requirements of the local governments.
The impetus for use of COBIT has evolved from just supporting internal audit to a means of organizing multiple frameworks and as a means for connecting overall enterprise objectives to the governance and management of IT assets.
In May 2006, the government of Turkey mandated the use of COBIT for banks operating within Turkey.2 The Banking Regulation and Supervision Agency of Turkey (BRSA) mandated that all banks operating in Turkey must adopt COBIT’s best practices when managing IT-related processes. The result of this legal requirement has been that internal auditors and bank management have put into place resources based on the process descriptions used in COBIT. Compliance reports are now submitted to government officials to demonstrate adherence to COBIT process and practice descriptions. There have been other government mandates for the use of COBIT in Costa Rica and Nigeria.
These uses were not foreseen, but they are understandable, natural extensions of the framework. The potential for a comprehensive framework is to use it to administer resources such that greater efficiency and effectiveness are realized and value is created for stakeholders. IT resources are ubiquitous, and the potential for IT spending without clear alignment to overall strategic aims is high. That risk of misalignment is a control issue.
Fast Change, Faster Response
One area where this issue is particularly impactful is in the arena of new and emerging technologies—particularly those that have a high potential for “shadow IT” adoption (i.e., adoption without central oversight such as by IT or another organization). In many cases, an enterprise can become aware that users have begun adopting a new technology only after that technology has begun to proliferate throughout the enterprise as a whole.
When that happens, resources can be consumed in a way that does not align with enterprise requirements nor directly or indirectly progress the prioritized goals of the enterprise. This is obviously undesirable as it can divert time and attention away from those activities and investments that do tie directly to those goals and anticipated or desired outcomes. The issue is further compounded as, in many cases, senior management is unaware that this resource strain is even occurring in the first place. Cloud services is an example of this (in particular, software as a service [SaaS]), mobile technologies (whether bring your own device [BYOD] or otherwise), and social media. It does not take an extraordinary level of insight to see that these disruptive changes, when adopted without a workmanlike and disciplined approach, can bring about potential areas of risk, introduce potential inefficiencies and spark other undesirable outcomes.
COBIT already provides the means to manage technology resources no matter their origination, purpose, internal user community or other defining factors. Organizations can already adopt and apply COBIT 5 (as it exists right now) in such a way that all technology use is deployed, managed, measured, and otherwise aligned with stakeholder needs and business goals. This puts organizations in the position of being able to lessen the potential disruptive impact of new technology, better manage and control risk, and directly measure the value to the business (even of “shadow IT”) against the business value provided through the use of new technologies. Looking forward, though, a primary area of further growth for COBIT lies in the ability of the framework to provide value as the pace of change accelerates and as operational technology and traditional IT merge.
Governance
It does not take a rocket scientist or an especially astute prognosticator to be able to state a few things with confidence about where enterprise technology use is heading in light of the trends we are seeing in the marketplace already. First, we can state with confidence that a proliferation of devices will likely occur as the Internet of Things (IoT) continues to expand. Likewise, we know that certain sectors that have specialized operational technology (i.e., the clinical network of a health care provider, industrial control systems, specialized networks used for telecommunications, broadcasting or other industries that require high-speed or specialized transmission) are likely to see their existing specialized technology use continue and, in fact, become even more specialized in supporting the way that they do business tomorrow.
While the COBIT framework can be used already to address these challenges head on, there are opportunities to provide more and better guidance to practitioners about how, specifically, to do this. For example, specialized supporting artifacts and tools to build upon the COBIT framework can provide immediate value to the practitioner so they are not “reinventing the wheel” separately from enterprise to enterprise. Tools that are immediately practical to the professional in the field—such as templates to support deliverable creation and reporting; governance artifacts such as policy examples and templates; and tools that support measuring effectiveness, managing risk or other activities to support robust governance—are a necessity given the pace at which technology use evolves and the likely even more rapid pace at which it will evolve tomorrow.
These items and others that directly target an increase in the practical value of the framework to the practitioner are on the forefront of the COBIT research agenda. Just as COBIT evolved over the last 20 years to meet the changing landscape of enterprise and become a framework for systematic governance of enterprise IT (GEIT), the future will mean continued evolution to address a systematic framework for governance as “information technology” becomes just “technology”—as usage and scope expand beyond the borders of the IT department and become embedded in the fabric of the business more generally. Likewise, as the alacrity of change (and the pace of disruption that occurs as a result) continues to increase, the framework will continue to evolve to meet those needs.
Peter Tessin, CISA, CRISC, CGEIT
Is a technical research manager at ISACA where he has been project manager for COBIT 5 and has led the development of other COBIT 5-related publications, white papers and articles. He also played a central role in the design of the COBIT online web site. Prior to joining ISACA, Tessin was a senior manager at an internal audit firm where he led client engagements and was responsible for IT and financial audit teams. Previously, he worked in various industry roles including staff accountant, application developer, accounting systems consultant and trainer, business analyst, project manager, and auditor. He has worked in many countries outside of his native US including Canada, Mexico, Germany, Italy, France, UK and Australia.
Why is it that some companies succeed and others fail? There is a general consensus certain things are common among successful companies. We call these things key success factors. Key success factors are essential attributes that are critical to an organization reaching its business goals.
There is no agreed-upon list of success factors because they vary depending on the nature of the business, among other things. Some business experts would say good, productive employees are a key success factor. Others believe keeping loyal customers is a critical factor. Still others would submit that having clear policies and procedures is how organizations succeed.
I would not disagree with any of these. However, as a Certified Information Systems Auditor (CISA)and a former IT auditor and manager, I would suggest that having an effective audit function is critical to the success of a business. The purpose of an audit is to evaluate an entity, such as a policy, process or account, to ascertain if it meets a predetermined standard or criteria.
Cybersecurity Ripe for Audits
A successful audit should identify areas of the organization needing improvement, including those that are likely to be high risk. In today’s digital environment, cybersecurity is typically top of mind for company leaders. They often know enough to be concerned, but not enough to actually address those concerns. In other words, there is no question that cybersecurity is an area of high risk for most organizations, but how they should respond to this risk is unclear.
It is the job of the IT audit function to determine how the organization should respond to risks that are specific to their operation and then evaluate whether the response is appropriate based on auditing standards and best practices. One common response to mitigate risk is to implement countermeasures, also known as controls. In those situations it is the responsibility of the auditor to evaluate the effectiveness of the controls to determine if they will indeed work.
For example, business leaders often believe that a firewall is a sufficient response to cybersecurity concerns. Some questions IT auditors will ask these situations include, What type of firewall is it? How has it been configured? How often are the rules updated? The IT auditor will also inform senior management that a firewall is only one of many controls that should be considered when responding to the threat of a cyberattack.
While the audit team should be actively involved in the tactical procedures of auditing the company, a skilled audit team that partners with the board of directors and senior management will not only identify aspects of the company that need attention, but also develop an audit plan that supports the organization’s overall strategy and act as consultants to help move the company closer to its vision. Over time, with the ongoing involvement of the audit team on the tactical and strategic levels, the organization can certainly count audit as one of its key success factors.
Note: For more on auditing cybersecurity, view this article in @ISACA.com.
There have been recent articles and blog posts arguing that the API approach is better than the proxy approach when it comes to selecting a cloud access security broker (CASB). The argument doesn’t really make sense at all. Both surely have their advantages and disadvantages, but each covers unique use cases and while you could certainly select a CASB that supports one versus the other, why not choose a CASB that offers both so you have the option to combine the two and address expanded use cases?
Pitting one against the other is like comparing a spoon vs. a fork. A spoon was designed to hold softer food in addition to liquid so you can place it in your mouth and eat a meal. Spoons come in various sizes depending on the application. In a similar fashion, an API deployment method is primarily focused on a set of specific use cases that includes being able to inspect content in sanctioned cloud apps and support for out-of-band policies such as restrict access, revoke shares, quarantine, and encrypt.
A fork on the other hand, was designed primarily to grab and hold solid foods for eating. That is a job that the spoon cannot do. In a similar fashion, a proxy deployment method is primarily focused on a specific set of use cases around providing real-time visibility and control over cloud traffic and depending on the type of proxy, you can cover both sanctioned and unsanctioned cloud apps in real-time. Real-time and covering unsanctioned cloud apps is not possible with an API deployment method. In addition to use cases, there is the comparison of effort to deploy and use. You can argue that a fork requires a bit more care versus a spoon. You might not give that fork to a toddler for example, but a spoon would be less risky with trade-off of course that they might have a hard time eating their vegetables with that spoon. Similarly, a proxy requires and inline deployment and a forward-proxy specifically requires extra configuration and care. The effort can be worth it given the use cases.
Let’s get back to my original argument that why choose one versus the other? Choose a CASB that covers both an API method of deployment and multiple proxy methods of deployment. You can choose only one or combine them to expand your use case coverage. Should we start calling API + Proxy a spork?
Here is a table that compares use case coverage for API vs Proxy to help you make the decision which one to choose or perhaps choose both.
Bob Gilbert, Vice President/Product Marketing, Netskope
In case you were off enjoying a well-deserved summer holiday and are, like I am, a firm believer in disconnecting from the world while on holiday, you might have missed the recent hacker document dump of the U.S. Democratic National Committee (DNC) emails. Personal note: if you did find a place remote enough to not hear about this, please send me the coordinates as I want to visit there ASAP.
Information security professionals have long operated under the mantra ‘prevention is ideal, but detection is a must.’ Many professionals have extended that mantra to include the concept of ‘response’ to detection. Usually response is considered in terms of technical tools to speed remediation and improve prevention of future attacks. The DNC hack, like many other hacks before it, highlights the financial value of knowing what was in the data that was exposed.
When it comes to evaluating the monetary value of knowing what data is exposed, ransomware is the ultimate capitalistic exercise. Hackers attempt to determine the right balance of 1) The organization’s tolerance to data loss, including the safeguards the organization may have in place; 2) The value the organization places on the data; and 3) The value they place on public knowledge of a data loss incident. The ransomer’s goal is simple, set a price point that the organization is most likely to pay.
While ransomware is foremost in many of my conversations with C-level executives, the danger of an insider threat is also a recurring topic of conversation. In the past six months I’ve been asked for help with the following:
“Our top designer went to work for our biggest competitor, what data did they take with them?”
“We had a friendly merger with another firm but their top 6 engineers left shortly after the merger, did they take any data with them?”
“One of our senior execs laptops was stolen; do we have any government mandated reporting requirements?”
All of these are questions ultimately seek to assign a dollar value to knowing what data was exposed and what information was in that data.
A well-designed modern endpoint backup solution can help you know the value of your data and remediate those threats by:
Performing point-in-time restores to before ransomware hits.
Showing you what data was copied to USB devices or personal cloud accounts before an employee leaves your organization.
Helping you determine what data was on a stolen device and the extent of your exposure.
Making it easy for employees to restore their data after a viral ransomware incident.
Never paying a ransom.
For years, those of us in the backup space have defined our value proposition as: Knowing what data was on a device that crashed/was lost/was stolen. Modern endpoint backup extends visibility to the data on a device that was compromised by an insider or a hacker.
