It has become almost impossible to face cybersecurity issues just by using the presently available countermeasures; hackers always find aways to bypass them. Whatever the future state of technology, some information related to people and national security must be kept secret. To propose a viable response to this situation, Octosafes Inc. conceived a theoretical system based on 5 hypotheses and mathematic chaos laws. The 5 hypotheses are:
- A child born today can be identified and authenticated by a computer without using the child’s name or a numerical identifier (SSN).
- On a certain scale, e.g., micron (micrometer) or microsecond, it is impossible for 2 people or 2 objects to be exactly the same, e.g., identical twins, fingerprints or 2 sheets of paper in the same ream.
- To become safer or even impenetrable, information systems must obey new laws and new logic (other than Boolean logic).
- The computer can protect people by protecting itself.
- Based on the previous hypotheses, it is now possible to design information systems with limited compatibility, i.e., it is impossible for 2 computers to communicate if there has not been some “physical” interaction (remotely or not) between these 2 systems.
The 2 essential laws of chaos theory are:
- Some degree of uniformity and order can be found in apparently erratic and uncontrollable phenomena.
- A phenomenon that is very controllable and predictable can become very unpredictable over a long time period
Based on these observations, mathematicians were able to create patterns they called strange attractors. They have also discovered dimensions of space that are no longer whole and that can be replicated to infinity.
Our recent Journal article is based on these 5 hypotheses and on the integration of chaotic models in information technology. However, it is rare for a mathematical abstraction to totally fit with reality, so we used a type of stratagem to integrate chaotic processes into the digital card that is at the center of our IT security project. Because this card will be made billions of times and the spatio-temporal coordinates of each card are unique, any attempt to clone or reproduce this card is doomed to failure.
The actual structure of each card is revealed and stored in the authentication server (AS) using a microlaser scanning the surface of each card at a specific frequency, which is determined at the time of initialization, i.e., from the first card and AS interaction. This single reading at submillimetric scales and microsecond time slots will be similar to the outline of a beach (designed at a millimeter scale) after each ebb and flow of the waves. Each grain of sand that moves changes the outline of this beach, and its analysis even with the most sophisticated devices becomes complex or even chaotic. With regard to our card, these ebb and flow movements have been replaced by frequency variations. At a frequency x, the microlaser can be in a hollow, and at a frequency y, it can be on a bump. Because these hollows and bumps are imperceptible to sight and touch, it is impossible for a human to control them for wrongdoing. In addition to these obstacles coming from the physical structure of the card, others that are equally unpredictable can be added, such as the biometric and genetic data of the card owner, the variations in the time of the records, the corrections after writing some wrong information, etc.
By introducing chaos mathematic laws in cybersecurity, the hope is to initiate other logic and other electronic circuits that go beyond the Boolean algebra. In fact, the Boolean logic is still utilized in our system, but some other parameters (based on our 5 hypotheses) help to significantly modify this logic by introducing, for the first time, some notions such as “the computer can protect itself” or it is possible, thanks to the evolution of technology, to conceive “some systems with limited compatibility."
Read Jean Jacques Raphael, Jean Claude Célestin and Eric Romuald Djiethieu's recent Journal article:
"Chaos to the Rescue," ISACA Journal, volume 4, 2019.
How do you transform security and privacy compliance requirements into practical steps that can be executed by a team? It is not easy, especially in an Agile environment that wants to move quickly—to say there exists a gap between complying with policies, and actually executing tasks to that end is just the tip of the iceberg. The rest of the iceberg looks like this:
- Policies, regulations and standards are designed to be high-level and abstract. There are no simple steps to follow to meet them.
- Policy-to-execution (P2E) platforms are limited to technical steps for only the software development life cycle (SDLC).
- Regulatory bodies continue to publish new standards beyond the SDLC.
- Organizations may perceive security as a disruptor.
For instance, section 4.2 of the PCI-SSLC requires that "[n]ewly discovered vulnerabilities are fixed in a timely manner. The reintroduction of similar or previously resolved vulnerabilities is prevented."
This directive is tantamount to “perform security testing using techniques such as dynamic application security testing (DAST), static application security testing (SAST) and interactive application security testing (IAST),” but there is no indication about how to go about that. Even the most security-conscious developer would not know where to begin. The framework we propose in our Journal article tackles the gap we see here between the need to comply with a regulation and the lack of actionable tasks to do so.
Effectively translating this policy into actionable tasks requires research. We started with literature reviews of existing workflows and controls for security testing. We sought the following:
- The identification of gaps
- The analysis of gaps
- The definition of actionable steps
Next, we interviewed subject matter experts (SMEs). These are the kinds of questions we wanted answered:
- What are the existing methods in use for performing these tasks?
- How often should a task be performed?
- What are the relevant roles and responsibilities in your team?
We used these answers and criteria to create a list to:
- Determine processes to perform a task beyond simply the SDLC from beginning to end.
- Determine an owner for each task.
- Automate by integrating with DevOps tools.
Developing securely by design is the way forward, and as technology evolves, new controls and standards arise to meet the need to develop secure and compliant applications. Meeting those controls, however, is not straightforward without a consistent method to convert policy to procedure without colliding into an iceberg.
Read Mina Miri, Amir Pourafshar, Pooya Mehregan, Nathanael Mohammed's recent Journal article:
"Bridging the Gap between Policies and Execution in an Agile Environment," ISACA Journal, volume 4, 2019.
My recent Journal article on the Internet of Things (IoT) was inspired by an article I read on a botnet takedown that involved the digital recording devices that many people have connected to their television. It reminded me of the information security problems that came to light as new computer software was developed and used by many organizations and people. When the personal computer industry was in its infancy, there was no thought about misusing it (e.g., local denial-of-service attacks, adding malicious software to the computer). The only concern was getting it out in the marketplace and selling it. Information security and privacy were not a concern, device capabilities and features were.
We are in the same situation with IoT devices, as the basic components of the computer are the memory and processing chip, the software, and the storage device (i.e., hard or flash drive). IoT devices are very similar to if not actual computers. They have some type of data communications, they store programs, they process and store data, and they possess the capability/weakness of being misused.
In my article, I identify the botnet components, list many IoT device vulnerabilities and talk about the types of attacks (and actual security incidents) that have taken place against various IoT devices. I review the information security and privacy concerns of home, office, and personal IoT devices, and my article identifies many of the common concerns. Recommendations for organizations, IoT device manufacturers, and the home and business are also included.
My intent is to make you aware of the possible weaknesses in these devices and how they can be a threat to you, your family, your well-being and possibly your place of work.
Read Larry G. Wlosinski's Journal article:
"The IoT as a Growing Threat to Organizations," ISACA Journal, volume 4, 2019.
The explosion of DevSecOps has caused a lot of excitement and worry within the cybersecurity community. It is no longer of question of should an organization implement DevSecOps, but rather when and how? While the scope and complexity of DevSecOps may initially seem daunting to security professionals, there are a few important points that can be kept in mind to implement an effective DevSecOps programs that can enable an organization to increase the velocity of their software releases but remain secure at the same time:
- Remember that tools are your best friend. The speed of DevSecOps makes manual testing/review simply too cumbersome to be effective. Find out which security tools best fit into your delivery pipeline, and work with the teams to effectively integrate them so that your security controls are an integral part of the framework. At a bare minimum, you should be having secure code reviews and automated security scanning for every software deployment.
- Automate the decision-making process. One of the key things I realized during implementing security controls in DevSecOps is that none of the automated security testing mentioned previously will make any difference if decisions are not made immediately based on their results. Jobs need to intelligently succeed/fail based on security success criteria that the security professionals and developers need to sit together and define. Certain things will be showstoppers for which the developers will need immediate feedback, while others can be fixed later, but this decision-making framework needs to be automated, with immediate results being sent back to all relevant teams.
- There is no escape from coding. As much as I would like to say that every organization has enough budget to hire dedicated security professionals with deep coding experience, that is simply not realistic. DevSecOps often needs security professionals to roll up their sleeves and dig in to the code to find out why jobs are failing, application programming interface (API) calls are not being triggered, etc., and developers will get frustrated if security professionals are not able to provide answers for such problems. Investing in security training for developers and coding training for security professionals will reap huge dividends in the future and help break down silos, enabling a faster cultural shift to DevSecOps at the ground level.
Read Taimur Ijlal's recent Journal article:
"Three Strategies for a Successful DevSecOps Implementation," ISACA Journal, volume 4, 2019.
Unpatched systems represent a very serious IT security threat with potentially extremely important consequences, as documented in a large number of high-profile breaches that exploited known unpatched vulnerabilities. Since these vulnerabilities are known, not just to attackers, but also to system administrators, and since patches exist, it is on first look surprising that unpatched systems even exist. The reality, however, is that patching is not that simple: Because of interdependencies, it must be verified that the patch is compatible with everything else in the system, e.g., an operating system patch must be compatible with the applications and databases running on top of the operating system. Sometimes, they are not, as manifested, for instance, in the recent Spectre and Meltdown vulnerability, where some application providers explicitly warned against patching. Verifications mean testing by other vendors, and this may not be a high priority for the application vendor, with an answer or full solution sometimes coming with the next release. Today’s organizations typically employ a large number of systems and applications, and making sure all of them are patched promptly is not automatic.
In light of this situation, organizations need to bolster the first line of defense, i.e., do everything possible to ensure prompt patching and, in addition, prepare a second line of defense to deal with systems that cannot or will not be patched in a reasonable time frame. Such a strategy could entail:
- Involve high-level management who need to be aware of the risk and attempt to obtain contractual guarantees of prompt addressing of patch issues, whether in their system or application or in other systems their own systems depend on. Evaluate vendors in this respect.
- Establish a clear line of ultimate responsibility for patching. This involves appointing someone to monitor and assess the patching risk and empower that person to carry out this task. This involves, among others, an architectural map of the systems, their function, criticality and exposure (e.g., Internet-facing) plus interconnections, as well as a monitoring tool carrying out regular scans with respect to patching.
- Contact the vendors regarding patch testing, compatibility and availability, and possibly carry out tests internally if necessary.
- Propose blacklisting irresponsive vendors.
- Propose and implement (in cooperation with relevant company units) alternative mitigating measures in case patching is not possible in a reasonable time frame. Such measures could involving agents in the unpatched systems to block exploits (although unlikely to be accepted by the vendor), putting patched intermediate servers in the path to the Internet to inspect incoming traffic, and using web application firewalls (WAFs) or sandboxing-type solutions, always taking into account possible performance issues.
- Especially if one must live with unpatched systems, monitoring and responding to rogue activities gains importance.
Read Spiros Alexiou’s recent Journal article:
“Practical Patch Management and Mitigation,” ISACA Journal, volume 3, 2019.
The nature of risk management has changed over the past 2 decades. Previously isolated IT infrastructures are more connected with the outside world, and organizations face an ever-expanding threat landscape. Most organizations operate in a reactive mode, typically driven by an outside-in fear and avoidance approach where priorities are based on the latest known threat or new regulation. The challenge with this approach, in addition to it being reactionary and driven by outside forces, is that it promotes a keep-the-lights-on mentality, results in an inefficient use of resources and distracts from the priority of protecting an organization’s most critical data assets.
The motivation is primarily the fear of fines and reputational risk. For a security program to succeed and reduce information technology risk, a focus on driving business value by effectively mitigating risk wherever it may live is preferred.
The Risk IT Framework developed by ISACA includes the following core principle: Make IT risk management a continuous process and a part of daily activities.
This tenet is prescient because today’s threat landscape never sleeps. Digital transformation, SensorNet, cloud and DevOps are creating dramatically expanding attack surfaces. Attackers are constantly looking for a way in, and employees are finding new ways to accidentally expose sensitive information. Annual penetration tests or security reviews do not cut it. Regulatory-focused security programs cannot keep up. So how can organizations move from a reactionary approach to a proactive, risk-centric program?
- Know your business—Understand what information is most important to the organization. Understand what information assets drive the business and need more protection. One-size-fits-all security is not effective and can add substantial costs when it is not warranted. Talk to internal department leaders and get to know how security programs can add value to their lines of business.
- Conduct a comprehensive risk assessment—Doing so will uncover where gaps in your existing programs are against appropriate regulations, standards and best practices. An assessment will provide a risk model to help identify the most likely attackers, assets they are most likely to go after and the overall impact to the organization in case of an incident.
- Do not stop at a checklist—While a thorough assessment will provide a list of items to be addressed, move beyond a simple checklist. Each identified gap should be surrounded by control, planning and continuous risk monitoring.
Information security and risk management are not easy fields in which to succeed. These 3 basic steps can help you start transforming your organization’s approach to cybersecurity. The benefits of doing so include reducing security technology clutter, minimizing operational expenditures, and creating a program that is business aligned and more effective at reducing risk.
Read Brian Golumbeck’s recent Journal article:
“Moving Risk Management From Fear and Avoidance to Performance and Value,” ISACA Journal, volume 3, 2019.
Managing cyberrisk is critically important for organizations. Interconnectedness, digitization, the focus on utilizing data and providing enhanced client experiences expand the attack surface and expose an organization to increased cyberrisk. I cannot think of a worse experience for a board member than to be told (or to read in a newspaper) that the organization’s client database has been leaked online, that a significant amount of money was stolen or that the organization cannot operate because all the servers have been locked up with ransomware. No organization can be 100% secure, and bad events will happen. There are, however, practical steps that can be taken to reduce the risk of a cyberevent happening and, when it does happen, to recover the organization to the same state as before the event.
The difficult question is where to start managing cyberrisk, especially if the organization is not yet focused on cyber. I would advise against just jumping in and start implementing cyberactions. The most important task to start with in my view is to create a cyberresilience program with executive support. This task can be quite difficult, but without executive support, a vehicle for all the tasks that must be done and a report to keep the board informed of the cyberjourney, cyberrisk management will be dead in the water, and the organization will just be waiting to become a victim of a cyberattack. This becomes more difficult especially in organizations that have not experienced a cyberevent. I will not be surprised if there are many organizations where the extent of cyberrisk management is a technical team buried in the IT department that focuses on hardware and security settings.
Although I mention it in my Journal article, I recommend doing a current-state cyberrisk assessment first. Procure the services of a respectable external consulting firm to do the assessment. Openness, transparency and honesty are the keywords for this step. The cyberpractitioner will know many of the things that are not in place in the organization and should provide that information to the assessment team. Once the attention and commitment of the board has been obtained with an external report, the next step is to create a cyberresilience program. In this step, focus on ranking the items discussed in my article over a period of 2 or 3 years. It will not be possible to do everything in year 1 as it will be too expensive, and the resources will not be immediately available to address everything in one go.
It is very important that the board understand cyberrisk; therefore, implementing board reporting and promoting executive awareness should be high in priority of the 3-year plan. It does not matter if the first report has lots of red items. The more informed the board is—especially board members from the business lines and, more importantly, if they understand the impact that a cyberevent can have on their organizations—the greater the chance will be of obtaining resources to implement the cyberplan. The board report is probably one of the most important tools a cyberpractitioner has and should be utilized effectively to manage cyberrisk and to describe the cyberjourney to the board. I am of the opinion that an organization should not attempt to describe the end-goal for cyber, but rather to describe the journey and that the right actions are being taken along the journey to reduce cyberrisk. The next step is to adopt a cybermaturity framework against which to measure the organization internally. Armed with these tools, the other steps in my article can be mapped out and implemented, e.g., identifying the crown jewels, threat modelling, determining if controls are adequate to protect critical points along the kill chain, red team testing, etc., and each item that is implemented will improve the organization’s cybermaturity.
Read Jaco Cloete’s recent Journal article:
“Practical Cyberrisk Management,” ISACA Journal, volume 3, 2019.
Cybersecurity is an endless process of chasing and preventing known attacks; anticipating attacks; and monitoring, alerting, patching, remediating and implementing solutions. It is becoming a maintenance function that trails hackers and other bad actors.
Cyberresilience refers to the ability to constantly deliver intended outcomes despite negative cyberevents. It is keeping business intact through the ability to effectively restore normal operations in the areas of information systems, business functions and supply chain management. In simple terms, it is the return to a normal state.
Cyberresiliency is the ability to prevent, detect and correct any impact that incidents have on the information required to do business. Examples of the enterprise cyberresiliency goals are:
- Anticipate—Stay informed and ready to expect compromises from adversary attacks.
- Withstand—Continue the enterprise’s mission-critical business operations despite a successful attack by an adversary.
- Recover—Restore mission-critical business operations to pre-attack levels to the maximum extent possible.
- Evolve—Change missions/business functions and/or the supporting cybercapabilities to minimize adverse impacts from actual or predicted adversary attacks; change cybercapabilities for mission-critical business operations to minimize impacts from the actual or predicted adversary attacks.
Cyberresiliency has progressed to enable enterprises to withstand and rapidly recover from cyberattacks that have a criminal intent to induce harm, cripple and extort enterprises. Cyberresiliency is a board-level responsibility with high business content. It is based on initiatives under the auspices of corporate governance, enterprise cyberprograms and supply chain network.
The trend and severity of serious cyberbreaches underscores the fact that enterprises will face a serious breach with intent to harm. The organization and its board of directors (BoD) ought to, in anticipation of such an attack, plan how to withstand it, rapidly recover from it, and how to evolve to reengineer its business and cybersecurity processes.
It is the enterprise’s responsibility to evaluate and measure its current state of cyberresiliency and how to transform itself to strengthen its cyberenvironment to withstand serious cyberthreats.
A methodology was developed to build a cyberresiliency decision model (CRDM). It quantifies and compares the degree of impact of each proposed cyberresiliency initiative on any of the enterprise-stated goals and objectives and develops a road map to the containment of the threats.
Determining the portfolio of cyberresiliency investment and the realized value of such initiatives is highly correlated with an organization’s willingness to articulate the following:
- The risk of potential costs of security incidents that the enterprise is willing to bear
- The level of risk that the enterprise is willing to accept when running its business
- The enterprise’s recognition that investment in cyberresiliency ought to be mapped and prioritized to the desired outcome and types of threats.
Read Robert Putrus’ recent Journal article:
“Enterprise Transformation to Cyberresiliency,” ISACA Journal, volume 3, 2019.
In the past 5 years, the cybersecurity agenda has been raised and discussed and in many forums because cyberattacks have been developed for various purposes, and the number of cybersecurity incidents or data breaches have increased dramatically every year. After major incidents around the world in the past few years, cyberattacks have caused several impacts on public services, business, people and even the accusation of the cybercrime from others. Therefore, many countries, such the United Kingdom, German, Estonia, Australia, Canada and Singapore, have developed and issued laws to take action on cybersecurity, such as the national strategy, guidelines of implementation and reporting. Generally, all cybersecurity acts are focusing on industries identified as critical infrastructure (CI) or critical information infrastructure (CII) of the nations, such as national security, financial, telecommunication, public transportation and logistics, healthcare and energy sectors. These sectors are always the first primary target of cyberattacks and cause the biggest business disruption or impact nationwide.
The Thai government will soon issue the first cybersecurity bill, which aims to level up the cybersecurity safeguard, minimize or control cyberrisk and create cyberresilience in CII organizations. According to the bill, the law will focus on the incidents or crises of CII that have impact on public services or could even cause death or injury, rather than individual computer crimes or monitoring behavior on the Internet. The CII has been categorized into at least 7 groups, which are: national security, public service, financial service, information technology and telecommunication, supply chain and logistics, public utility and energy, and healthcare.
The new cybersecurity agency created by the bill will be responsible for enforcing, cooperating with other regulators and international organizations, supporting, responding to cyberincidents and regulating the CII organizations. The law contains the obligations and several penalties for noncompliance. In addition, the law also contains details of how CII can be compliant with this law, which relates to risk base management concept and 5 functions of the US National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF) version 1.1 (i.e., identify, protect, detect, response, recover). Therefore, all CII enterprises are now facing the challenge of complying with the law and other coming regulations, which will provide more implementation details for the bill, especially the operation technology (OT) and public services. The OT is claimed to be in the closed network system (no external or Internet connection) for a long time, while public services sometimes focus on the service and avoid the security issues due to the service volume. These areas must be improved as fast as we can by using the NIST framework as the implementation guideline or other IT security standards, such as International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 27001 or European Union Agency for Network and Information Security (ENISA) guidelines. The area of the cybersecurity development or improvement in the organization must be covered all aspects of people, process and technology.
Last but not least, for the implementors or compliance, ISACA has published the Implementing the NIST Cybersecurity Framework to enable practitioners and enterprises to gain an understanding of the CSF and its implementation.
Read Nipon Nachin, Chatpong Tangmanee and Krerk Piromsopa’s recent Journal article:
“How to Increase Cybersecurity Awareness,” ISACA Journal, volume 2, 2019.
Organizations have diverse understandings of what digital security is and is not. As a consequence, they wrestle with who is responsible and who is accountable for digital security. This further complicates the question of whether the chief information security officer (CISO) position ought to be considered and instituted. CISO positions and responsibilities are greatly unsettled because digital security crosses many aspects of enterprise transactions, challenging if it is even possible to place boundaries on the responsibilities of the role.
Do organizations expect the CISO to be a technology wizard, business savvy or a hybrid of both? Do organizations expect the CISO to be the responsible and accountable person in securing the computing environment and informational assets in the enterprise? Should the CISO be part of the executive team, or should the role be confined within the IT group?
The subject of digital security within an organization creates a dilemma within the executive team with regard to defining the CISO role within the organization. There are several key gaps between what senior management may want or expect from the cybersecurity function and how far-reaching the responsibility of the CISO role ought to be that can be identified, and it is important to understand how to bridge and mitigate those gaps.
The CISO can be involved in a wide spectrum of responsibilities depending on the organization’s size and/or the lens the executive team looks through for digital security.
In my recent Journal article, I stated several gaps of understanding by CISO professionals as to how they perceive their role and what is the experience expected of them. The following are a few critical gaps:
- Gap 1: Should the CISO transform from having technical focus to a business focus?
- Gap 2: To whom should the CISO report?
- Gap 3: How does the CISO justify a digital security portfolio?
- Gap 4: Do organizations fully understand digital security functions?
- Gap 5: Is the CISO an IT function?
- Gap 6: Do the cloud and mobility present challenges?
Since the CISO position is being promoted to report higher in the organization chart, a greater emphasis is being placed on the CISO role and the expected skill level of those filling the role. It has moved the skill of the CISO from technical implementer of technology to one of business focus and the ability to oversee digital security as a vital business unit to justify its relevance and demonstrate the return on investment to the enterprise’s bottom line.
Additionally, enterprises are evolving to become risk-based organizations. This requires transformation of the enterprise culture to a risk-based culture, where digital security is the responsibility of all the employees of the enterprise.
However, such cultural transformation has put greater pressure on the CISO to be a trusted advisor who operates as the integrator of the enterprise business units and a relationship builder. Digital security is becoming the bridge to integrate the enterprise products and services with the enterprise business functions.
Read Robert Putrus’ recent Journal article:
“The Role of the CISO and the Digital Security Landscape,” ISACA Journal, volume 2, 2019.