One of the main tasks of the Information Technology Infrastructure Library (ITIL) implementation process is choosing an ITIL automation tool. Hence, while embarking on the IT service management (ITSM) automation journey, we should not rush into implementing a tool, even if the supplier claims that the tool has pre-built ITIL processes. First and foremost, we need to identify the existing gaps and the maturity levels in the 3 major domains, namely people, process and technology. The priority of these 3 domains should also be people, process and technology, respectively. Second, we need to ask specific questions for each of these 3 domains.
Questions that need to be answered in the people domain are:
- Does your existing organizational structure have adequate staffing in all ITIL-relevant areas? This includes help desk, desktop support, system administration and database administration.
- Are the job descriptions clear?
- Does each function have standard operating procedures (SOPs)?
- Is each function exposed to ITIL processes?
Questions that need to be answered in the process domain are:
- Does your organization have well-defined policies on all core processes, such as incident, change, release and service level management?
- Is each process defined in detail with work flows, notifications and escalation paths?
- Does each process have process owner(s)?
- Does each process also have a responsibility and accountability chart (RACI) for each activity within the process?
- How does your organization measure process efficiency? Have you defined the key performance indicators (KPIs)?
- Does your organization have well-defined service level agreements (SLAs)?
- Does your organization have well-defined business services and service catalogues?
Questions that need to be answered in the tools domain are:
- Does the proposed ITIL tool support ITIL-certified processes?
- Considering scalability and flexibility, can the proposed ITIL tool provide a cloud-based solution?
- Is the proposed ITIL tool modular and does it allow for implementation of specific processes?
- Does the proposed ITIL tool provide a strong configuration management database (CMDB) to manage the IT asset and configuration management?
- Does the proposed ITIL tool support a standard database (Oracle, SQL)?
- Does the proposed ITIL tool provide strong analytics to generate dashboards and KPI reporting?
- Does the proposed ITIL tool have functionality to support context-sensitive multi-channel self-service for users on mobile, Internet or tablets?
- Does the proposed ITIL tool include a unified portal covering self-service requests, knowledge management and dashboards?
- Does the proposed ITIL tool have flexibility in licensing models with named users (for high volume users) and floating users (approvers, low volume processes)?
- Does the proposed ITIL tool provide automated discovery tools to gather IT asset configuration data?
Finally, ensure all key stakeholders, including business management, technical support teams and call center employees, are a part of the project team.
Read Ram Mohan, Mathew Nicho and Shafaq Khan’s recent 2-part Journal article:
“Challenges and Lessons Learned Implementing ITIL,” ISACA Journal, volume 4, 2017.
There are far more ways to apply encryption incorrectly than there are ways to apply it correctly. Sadly, many people think they already know everything they need to know about encryption because they have read a few articles online. Recently, I published an article in which I discuss methods for assessing your HTTPS posture. While I was specifically focused on internal systems where you have some degree of control or are obligated to inform those who do have the degree of control, it is also extremely important not to overlook the necessity of performing the same type of assessment against vendor solutions.
Many times, I have pressed vendors for details regarding security only to receive the responses, “I do not have the information,” or my personal favorite, “It is encrypted.” Not having the information is inexcusable, and responding with, "it is encrypted" is arguably even worse. It implies they cannot articulate the details and they hope that you simply nod your head and not ask any further questions.
When considering HTTPS posture, there are a few key points to keep in mind. While these points do apply to internal configurations, they especially apply to vendor-provided solutions and information:
- Question everything. "It is encrypted" is a class of answers, not an answer on its own. The question is how it is encrypted. It is akin to someone asking what you like to eat and you replying, "food."
- If a vendor ever says that they use proprietary encryption (I am still shocked at how often I encounter this), it is a very bad sign. It borders on a statement of ineptitude.
- Evaluate what is meant when an enterprise says, "we do not share that information." Similar to the previous point, this statement implies the vendor does not fully understand the subject. If they were applying encryption correctly, they would proudly proclaim the details to anyone who asks.
- Ensure weak ciphers and protocols are explicitly disabled. It is not uncommon for a vendor to say something like, "we use TLSv1.2," and while this is ideal, it does not reveal what else is enabled. For example, using TLSv1.2 but leaving SSLv3 enabled largely defeats the purpose.
The previous points will help drive out the true encryption details. By clarifying these details, , the level of security not only increases, but the level of understanding of how security is implemented also increases.
Read Kurt Kincaid’s recent Journal article:
“HTTPS Posture Assessment,” ISACA Journal, volume 3, 2017.
There is a certain satisfaction that comes from turning the tables on a seemingly unbeatable adversary. Luke Skywalker exploited a design flaw to destroy the Death Star. Rocky Balboa exploited Ivan Drago’s arrogance to win a boxing round. Sarah Connor exploited a reprogrammed Arnold Schwarzenegger to beat the T-1000 in Terminator 2.
In cyber security, the hacker community often seems as evil as Darth Vader, as cold as Ivan Drago and as relentless as the Terminator. It would be nice if there were a way to turn the tables and beat hackers at their own game.
Whether for financial gain, social activism, mischievous vandalism or other malicious motivation, hackers have been exploiting weaknesses in human nature and network defenses and making life miserable for enterprises for decades. But today, security professionals are starting to turn things to our advantage. By amassing a knowledge of the millions of techniques known to be used by hackers and combining that information with real-time threat intelligence and continuous, automated vulnerability testing, it is possible to beat hackers at their own game.
Imagine, as in The Terminator, that you could see how an adversary attacked you, understand the weaknesses they would exploit, quantify which security defenses were failing and then go back in time to fix the problem before it happens. That is what we are talking about. And it is not a point-in-time assessment that may be valid today and obsolete tomorrow. It is a constant process based on up-to-the-minute analysis and intelligence.
It is important to use breach simulations to “breach your own castle.” It is a process that ensures not only that your investments in cyber security are calibrated to meet the specific needs of your enterprise, but it also creates a sort of incident response muscle memory that ensures a timely, efficient response when an attack does take place.
My recent Journal article goes into detail about my company’s approach, but to improve our industry’s readiness and efficacy, we believe in sharing information and in having a robust dialog that challenges assumptions and improves processes. In that spirit, I look forward to reading and responding to your comments.
Read Danelle Au’s recent Journal article:
“Breach Your Castle for Better Security,” ISACA Journal, volume 3, 2017.
Some Internet of Things (IoT) security issues and incidents can be attributed to poor knowledge, failure of the security manager to properly educate stakeholders or lack of stakeholder interest in investing in security measures. Some of this hesitance to invest in security comes from the desire to defer upfront or preventive security costs to operational or reactive costs. The cost deferment can be due to the lack of a proper risk model and failing to account for risk costs. In some situations, time pressures may also aid in deferring upfront security measures.
About 5 years ago, I started managing automobile sensors’ data integration architecture, and the term “IoT” was not even used at that time. Centralized device and security policy management was done through software built in-house, as commercial device management hubs were not available. Security policy management was not comprehensive. It was difficult and not cost-effective for every vendor to develop and maintain proprietary hub management software, so we needed to depend on a few industry leaders for such capabilities.
In my recent experience, I have come to realize that the IoT scope is not only limited to sensors, but should also include everything connected to the network in an organization, e.g., the IoT scope should include printers. This requirement arose from the fact that executives need to print extremely sensitive or extremely confidential documents. A few of my clients have now implemented smart card and pin-based authentication for such printers, which are also integrated with Active Directory. Printer security policies are managed through a proprietary printer management hub. The time to have a common printer management hub is still in the future.
Information departments in secure industries or in organizations lacking mature information management capabilities struggle with information silos. IoT environments in such organizations will also have similar devices or sensor silos, and implementing a common management hub to manage IoT security will pose a challenge. Thus, IoT security is not only technical in scope, but will also require a better understanding about departments, IoT hubs and data boundaries.
Read Hemant Patel’s recent Journal article:
“IoT Needs Better Security,” ISACA Journal, volume 3, 2017.
My recent ISACA Journal article discusses what every chief information security officer (CISO) must know about Secure Shell (SSH) key management. This is a topic that keeps me awake at night and should be of major concern to the whole audit community.
In short, SSH is a tool for systems management, automation and file systems, and it is used in every data center in every major enterprise. It introduced a new authentication mechanism based on cryptographic keys, called public key authentication. Unfortunately, in the default configuration, OpenSSH allows any user to provision new credentials for themselves and their friends, and these credentials never expire—not even when the user’s account is removed if the credentials have been added to a service account.
SSH keys can be used to violate segregation of duties—passwordless access using them from development into production systems is common. Attackers can also use them to spread laterally from server to server or data center to data center. This introduces an existential risk to enterprises, involving not only ransomware and exfiltration but also outright destruction and cyberwarfare.
We have found that many large enterprises have unprecedented numbers of these credentials configured—one customer found 3 million, and another had 4.5 million keys granting access to their environment—on tens of thousands of servers. The probability of being able to pivot from server to server using the keys is very high when combined with other attacks for privilege escalation (such as the recent memory management vulnerability in all Linux versions).
In my opinion, SSH access management has been the biggest risk in identity and access governance since we realized 20 years ago that many organizations had not terminated accounts for users that had left the organization. Today, most organizations do not have a process for terminating SSH key-based access, and some have accumulated 10 times as many SSH keys as they have users.
What keeps me awake at night is the thought of ransomware and other attacks spreading to practically all servers in a Fortune 500 company—including backup systems and disaster recovery data centers—using SSH keys. It can be done in a very stealthy fashion, and the outage could last months.
Read Tatu Ylonen’s recent Journal article:
“What Every CISO Must Know About SSH Keys,” ISACA Journal, volume 1, 2017.
The Internet of Things (IoT) is changing how people and technology interact. With billions of devices projected to be connected in the near future, the opportunity to be innovative is amazing.
In recent months, there have been several publications discussing the IoT, with many articles in favor of it and many against it. On one hand, it is said that all things should be connected: refrigerators, coffee machines, wearables, microwaves, umbrellas, fitness bands and drones. On the other hand, there is an opinion that this trend needs to be stopped, regulated or banned by government organizations because of security and privacy concerns. For example, the US Federal Trade Commission (FTC) publicly raised concerns about the security risk associated with the rising number of interconnected systems and devices.
But this is just the tip of the iceberg. Things are becoming even more connected. In fact, there is a flood of appliances that could potentially be or already are connected—without even giving a second thought as to whether or not these connection are necessary.
When we were writing our recent Journal article, we had a discussion about IoT that got us thinking that if our lives were controlled, monitored and directed by the devices that are around us, we may lose all sense of privacy and self-determination. We believe that this discussion will get deeper and deeper with the emergence and development of new IoT products.
But the future is now, and every day, new devices are connected. These devices are supposed to help improve the quality of life and they are making tasks for us, sharing information around the world and taking on a life of their own. But what about the security threats that they could produce?
Our recent Journal article describes the opportunities that the IoT could create and the challenges and risk associated with it. Every day the risk associated with the IoT increases; as technology advances faster and faster, so does the risk. When we wrote our Journal article, we could not anticipate IoT-related technology that is now on the market, just as we could not anticipate all of the new risk introduced from the time of writing this blog post to now. The IoT is becoming the next front for privacy litigation.
One of the most important concerns is the data security for Internet-connected devices. Security in the IoT is more important now than ever because of the amazing amount of new devices that are in use every day.
A holistic security management strategy has to be used with the IoT. A preventive security approach that considers the possible values new technology could create (while keeping in mind the risk that it could introduce) is the best way to maximize the benefits of the IoT.
Read Marcelo Hector Gonzalez and Jana Djurica’s recent Journal article:
“Internet of Things Offers Great Opportunities and Much Risk,” ISACA Journal, volume 2, 2015.
It is easy to second guess organizations after an attack as opposed to working with them on cybersecurity or information security initiatives. But this questioning can also offer some benefit, helping the security professionals learn what could have been done to defend the organization against the cyberattack. The following is a brief look at the attacks on Sony, Morgan Stanley and Anthem as a sample across the entertainment, financial and health insurance industries:
- Sony Pictures Entertainment (SPE) was the victim of a breach that exfiltrated more than 100 terabytes of data (47,000 records), after which large volumes of data were erased. Servers, networks and other infrastructure were rendered nonoperational.
- Morgan Stanley was the victim of an internal financial adviser who stole data on 350,000 clients using a reporting tool that gave him access to massive amounts of data on clients.
- Anthem suffered the disclosure of 80 million unencrypted customer and employee records accessed through stolen administrator credentials.
I would suggest that there are specific COBIT® 5 processes and practices that can be effective in halting or minimizing these types of attacks.
Evidently, there were weak processes in place to identify, assess and reduce IT-related risk (APO12 Manage Risk). Practically, there should have been a continuous collection of data for risk identification and threat analysis (APO12.01 Collect data). Organizations ought to collect data to understand evolving threats (including advanced persistent threats).
Organizations should conduct security assessments, vulnerability assessments and technical audits of their IT environment on a regular schedule (APO12.04 Articulate Risk). Reports from these assessments should be taken seriously with appropriate responses (APO12.06 Respond to risk). Key sources of threat intelligence and analysis (e.g., Financial Services-Information Sharing and Analysis Center) may not have been leveraged in the cases noted.
Security processes such as a formal information security management system (ISMS) should be established with clear scope, policies, organization, dedicated assets and technology (APO13.01 Establish and Maintain an ISMS). The organizations’ ISMSs may not have been fully developed.
A formal information security risk treatment plan should be defined with clear mapping of controls or security solutions against security-related risk (APO13.02 Information security risk treatment plan). Unencrypted personal information does not adhere to APO13.02.
Security services should be clearly aligned to risk (DSS05 Manage security services). It is possible that of the 7 technical practices in this COBIT 5 process, these victim organizations may have been lacking in the following areas:
- Malware defenses and network security controls as offered in next-generation firewalls. Further, intrusion detection systems may have been missing or dysfunctional (DSS05.01 Protect against malware, DSS05.02 Manage network security).
- Privileged access controls on systems administrators were weak and easily compromised by malicious actors (DSS05.04 Manage user identity), e.g., Weak access controls around sensitive information.
- Monitoring security events around the IT infrastructure was probably a major weak link (DSS05.07 Monitor the infrastructure for security-related events). This would include severity ratings and relevant indicators of compromise.
Read Fredric Greene’s recent Journal article:
“Selected COBIT 5 Processes for Essential Enterprise Security,” ISACA Journal, volume 2, 2015.
The selection of a security solution is a critical decision for an information security program. With the plethora of security solutions available, finding the best fit for an enterprise and its security needs can be a challenging and time-consuming task. When cost constraints are added to the picture, the selection process becomes even more problematic. There is a temptation to go with what is already familiar or select a solution that is already in use at a similar organization. But the best place to begin is by identifying critical functional requirements and restrictions for a security solution. The goal is to define, in a vendor-neutral fashion, a generic prototype of the security solution being sought. This should be done before doing any vendor research. This process should also spot potential attributes of a solution that may clash with the organizational environment.
While security staff should consider a wide range of security solution options, it is generally more cost effective and better time management to narrow the field. In absence of clear criteria, staff may feel obligated to include the whole universe of security solutions resulting in analysis paralysis. Established criteria narrows the focus to what the organization actually needs to eliminate gaps in its security perimeter, complement existing security technologies and processes, and achieve regulatory compliance.
The best way to assure that this occurs is to establish a defined and repeatable process to identify and select security solutions. A security solution needs to fit an organization like a great business suit. It needs to be custom-tailored to look and feel right and optimize the expenditure. It is critical to identify and evaluate security technology solutions to maximize the potential for a successful implementation.
Read Kerry Anderson’s recent Journal article:
“Evaluating Information Security Systems,” ISACA Journal, volume 2, 2015.
Cloud technology had a strong start because it followed the same development path as other systems. That path was to develop capabilities and add features to systems with little regard for information security. Over the years, cloud applications have emerged as software as a service (SaaS), platform as a service (PaaS) and infrastructure as a service (IaaS). Cloud systems are deployed as private, community, public and hybrid models. They are all over the Internet and are accessible by many types of mobile devices.
Over time, many cloud systems have crashed and incurred a variety of problems. Because of this and the fact that many people are not paying attention to these issues I wrote my recent ISACA Journal article, “Cloud Insecurities.” In the article I talk about the threats, vulnerabilities and weaknesses that people have accepted as a way of life and tend to ignore. Many of the article’s observations come from reading the Department of Homeland Security (DHS) Daily Open Source Infrastructure Report and from the Cloud Security Alliance (CSA) reports. To address the cloud problems, my Journal article suggests countermeasures that may or may not have been considered or implemented, and there are some questions that may help organizations think through cloud vulnerabilities.
When trying to develop a secure cloud system, it is important to remember:
- Not all programmers who develop cloud applications and tools have the same training or zeal for perfection.
- Not all cloud service providers (CSPs) run their data centers the same way.
- Not all organizations have the same software update and maintenance policy.
- CSPs may not have all of their systems configured to be perfectly secure.
- CSPs may use different operating systems and vendor software.
- There are criminal organizations and people who are looking for ways to take advantage of the information available on the Internet.
Developers, managers and computer operations should follow best practices and think about how important information security is and how many people are affected by it. The weaknesses in system configurations, product vulnerabilities, and account control and monitoring are not only common outside the cloud but also within cloud applications.
Endpoints, which include mobile hand-held devices, are changing and increasing in capabilities (and vulnerabilities) and the number of applications offered. Since the endpoint applications were developed the same way as cloud applications (i.e., security as an afterthought), they also contain weaknesses and vulnerabilities that criminals will eventually find and exploit. As consumers, it is important to be ever vigilant and also aware that many of the applications that are available have already been infected with malware or soon will be if users click a malicious link or go to an infected website. By loading malicious code onto mobile devices, users invite criminals to obtain personally sensitive information available in the cloud, and, worst of all, create a means by which criminals can access users’ hard-earned savings. So beware the applications you download. They may be your undoing.
Read Larry Wlosinski’s recent Journal article:
“Cloud Insecurities,” ISACA Journal, volume 2, 2015.
Seemant Sehgal, CISA, CISM, BS7799 LI, CCNA, CEH, CIW Security Analyst, SABSA
Advanced persistent threats (APTs) are a hot topic in the security arena today. There are a number of definitions and methods of identifying an APT. Some define it based on the extent of pinning it to certain attack vectors, while others map it to the complexity or time it takes to complete the attack. The term “targeted attacks” is the latest buzzword, gradually taking center stage as a new breed of cyberthreats emerge.
So how can one devise an effective strategy to combat such threats? Well, to do so, it is important to understand the implications of the words “advanced” and “targeted” in the cybersecurity context. Think of the example of a pickpocket looking for a prospective victim. A thief will skip stealing from targets when they are vigilant and instead look for someone whose guard is down. In other words, the attacker will go for the “low-hanging fruit” to find a way in.
Applying this scenario to the context of cyberthreats, the best strategy to combat an APT is to keep an eye on low-hanging fruit in your security ecosystem. Low-hanging fruit in this context represents the easiest vulnerability for threat agents to exploit and reach their target. It is important to remember that low-hanging fruit is not a static concept when it comes to cybersecurity. The moment you take the most obvious vulnerability out of the equation, attackers are going to take the next easiest route. As a result, the best combat strategy is that an enterprise stays situationally aware of the lowest hanging fruits it is offering to an attacker.
From a more global perspective, threats are targeted at a generic profile. Hence, for a threat to impact your values that are at risk, 2 conditions need to be met. First, the target profile must match the ecosystem that you present to the attacker. Second, your organization must be more easily exploitable than your next best competitor or another target presenting the same value to an attacker. If you want to make sure that your organization does not meet these criteria, the best strategy is to be situationally aware of the ecosystem your enterprise is a part of and ensure that you stay ahead of other like organizations.
However, when it comes to targeted attacks, the environment the enterprise is a part of does not matter. If the threat agents are motivated and committed to taking aim at you, they will. As with APTs, the best strategy to mitigate these targeted threats is to ensure that you are situationally aware of and continuously engaged in removing the low-hanging fruit from your security ecosystem. This way, you offer more complexity to an attacker and you have a better chance of combating targeted attacks.
Read Seemant Sehgal’s recent Journal article:
“Effective Cyberthreat Management Evolution and Beyond,” ISACA Journal, volume 1, 2015.