Social Icons

Featured Posts

About Us
Dyman & Associates Risk Management Projects is a Risk Management firm whose main office is based in Boston, MA. We operate in the following fields: Cyber Security, Project Management, Emergency Management, Technology Governance, and Physical Security. Our company is a minority-owned enterprise with both MBE & DBE certifications.

Quite often, organizations muddle through crises in isolation, undertaking prime decisions within a vacuum. Dyman & Associates Risk Management Projects has the collective know-how to minimize your exposure to risk and help make your business become more resilient. We will work diligently for your benefit. We believe that honesty, reliability, and excellent customer service serve as the foundation for lasting relationships. Moreover, we supply empathy, humility, and a promise to give back to our community.

Friday, August 8, 2014

Dyman Associates Risk Management: what is Risk Management

The Importance of Risk Management to Business Success

Risk management is an important part of planning for businesses. The process of risk management is designed to reduce or eliminate the risk of certain kinds of events happening or having an impact on the business.

Definition of Risk Management

Risk management is a process for identifying, assessing, and prioritizing risks of different kinds. Once the risks are identified, the risk manager will create a plan to minimize or eliminate the impact of negative events. A variety of strategies is available, depending on the type of risk and the type of business. There are a number of risk management standards, including those developed by the Project Management Institute, the International Organization for Standardization (ISO), the National Institute of Science and Technology, and actuarial societies.

Types of Risk

There are many different types of risk that risk management plans can mitigate. Common risks include things like accidents in the workplace or fires, tornadoes, earthquakes, and other natural disasters. It can also include legal risks like fraud, theft, and sexual harassment lawsuits. Risks can also relate to business practices, uncertainty in financial markets, failures in projects, credit risks, or the security and storage of data and records.

Goals of Risk Management

The idea behind using risk management practices is to protect businesses from being vulnerable. Many business risk management plans may focus on keeping the company viable and reducing financial risks. However, risk management is also designed to protect the employees, customers, and general public from negative events like fires or acts of terrorism that may affect them. Risk management practices are also about preserving the physical facilities, data, records, and physical assets a company owns or uses.

Process for Identifying and Managing Risk

While a variety of different strategies can mitigate or eliminate risk, the process for identifying and managing the risk is fairly standard and consists of five basic steps. First, threats or risks are identified. Second, the vulnerability of key assets like information to the identified threats is assessed. Next, the risk manager must determine the expected consequences of specific threats to assets. The last two steps in the process are to figure out ways to reduce risks and then prioritize the risk management procedures based on their importance.

Strategies for Managing Risk

There are as many different types of strategies for managing risk as there are types of risks. These break down into four main categories. Risk can be managed by accepting the consequences of a risk and budgeting for it. Another strategy is to transfer the risk to another party by insuring against a particular, like fire or a slip-and-fall accident. Closing down a particular high-risk area of a business can avoid risk. Finally, the manager can reduce the risk's negative effects, for instance, by installing sprinklers for fires or instituting a back-up plan for data.

Having a risk management plan is an important part of maintaining a successful and responsible company. Every company should have one. It will help to protect people as well as physical and financial assets.

Wednesday, August 6, 2014

Dyman Associates Risk Management Approach and Plan

Dyman Associates Risk Management – As a management process, risk management is used to identify and avoid the potential cost, schedule, and performance/technical risks to a system, take a proactive and structured approach to manage negative outcomes, respond to them if they occur, and identify potential opportunities that may be hidden in the situation [4]. The risk management approach and plan operationalize these management goals.

Because no two projects are exactly alike, the risk management approach and plan should be tailored to the scope and complexity of individual projects. Other considerations include the roles, responsibilities, and size of the project team, the risk management processes required or recommended by the government organization, and the risk management tools available to the project.

Risk occurs across the spectrum of government and its various enterprises, systems-of-systems, and individual systems. At the system level, the risk focus typically centers on development. Risk exists in operations, requirements, design, development, integration, testing, training, fielding, etc. (see the SE Life-Cycle Building Blocks section of this Guide). For systems-of-systems, the dependency risks rise to the top. Working consistency across the system-of-systems, synchronizing capability development and fielding, considering whether to interface, interoperate, or integrate, and the risks associated with these paths all come to the forefront in the system-of-systems environment. At the enterprise level, governance and complexity risks become more prominent. Governance risk of different guidance across the enterprise for the benefit of the enterprise will trickle down into the system-of-systems and individual systems, resulting in potentially unanticipated demands and perhaps suboptimal solutions at the low level that may be beneficial at the enterprise level. Dealing with the unknowns increases and the risks associated with these——techniques in the Guide's section on Enterprise Engineering, such as loose couplings, federated architectures, and portfolio management——can help the MITRE SE alleviate these risks.

Risk Management in System-Level Programs

System-level risk management is predominantly the responsibility of the team working to provide capabilities for a particular development effort. Within a system-level risk area, the primary responsibility falls to the system program manager and SE for working risk management, and the developers and integrators for helping identify and create approaches to reduce risk. In addition, a key responsibility is with the user community's decision maker onwhen to accept residual risk after it and its consequences have been identified. The articles in the Risk Management topic area provide guidance for identifying risk (Risk Identification), mitigating risks at the system level with options like control, transfer, and watch (Risk Mitigation Planning, Implementation, and Progress Monitoring), and a program risk assessment scale and matrix (Risk Impact Assessment and Prioritization). These guidelines, together with MITRE SEs using tools such as those identified in the Risk Management Tools article, will help the program team deal with risk management and provide realism to the development and implementation of capabilities for the users.

Risk Management in System-of-Systems Programs

Today, the body of literature on engineering risk management is largely aimed at addressing traditional engineering system projects—those systems designed and engineered against a set of well-defined user requirements, specifications, and technical standards. In contrast, little exists on how risk management principles apply to a system whose functionality and performance is governed by the interaction of a set of highly interconnected, yet independent, cooperating systems. Such systems may be referred to as systems-of-systems.

A system-of-systems can be thought of as a set or arrangement of systems that are related or interconnected to provide a given capability that, otherwise, would not be possible. The loss of any part of the supporting systems degrades or, in some cases, eliminates the performance or capabilities of the whole.

What makes risk management in the engineering of systems-of-systems more challenging than managing risk in a traditional system engineering project? The basic risk management process steps are the same. The challenge comes from implementing and managing the process steps across a large-scale, complex, system-of-systems—one whose subordinate systems, managers, and stakeholders may be geographically dispersed, organizationally distributed, and may not have fully intersecting user needs.

How does the delivery of capability over time affect how risks are managed in a system-of-systems? The difficulty is in aligning or mapping identified risks to capabilities planned to be delivered within a specified build by a specified time. Here, it is critically important that risk impact assessments are made as a function of which capabilities are affected, when these effects occur, and their impacts on users and stakeholders.

Lack of clearly defined system boundaries, management lines of responsibility, and accountability further challenge the management of risk in the engineering of systems-of-systems. User and stakeholder acceptance of risk management, and their participation in the process, is essential for success.

Given the above, a program needs to establish an environment where the reporting of risks and their potential consequences is encouraged and rewarded. Without this, there will be an incomplete picture of risk. Risks that threaten the successful engineering of a system-of-systems may become evident only when it is too late to effectively manage or mitigate them.

Frequently a system-of-systems is planned and engineered to deliver capabilities through a series of evolutionary builds. Risks can originate from different sources and threaten the system-of-systems at different times during their evolution. These risks and their sources should be mapped to the capabilities they potentially affect, according to their planned delivery date. Assessments should be made of each risk's potential impacts to planned capabilities, and whether they have collateral effects on dependent capabilities or technologies.

In most cases, the overall system-of-systems risk is not just a linear "roll-up" of its subordinate system-level risks. Rather, it is a combination of specific lower level individual system risks that, when put together, have the potential to adversely impact the system-of-systems in ways that do not equate to a simple roll-up of the system-level risks. The result is that some risks will be important to the individual systems and be managed at that level, while others will warrant the attention of system-of-systems engineering and management.

Tuesday, August 5, 2014

Dyman Associates Risk Management on How to Develop a Risk Management Plan

Developing an effective Risk Management Plan can help keep small issues from developing into emergencies. Different types of Risk Management Plans can deal with calculating the probability of an event, and how that event might impact you, what the risks are with certain ventures and how to mitigate the problems associated with those risks. Having a plan may help you deal with adverse situations when they arise and, hopefully, head them off before they arise.


1. Understand how Risk Management works. Risk is the effect (positive or negative) of an event or series of events that take place in one or several locations. It is computed from the probability of the event becoming an issue and the impact it would have (See Risk = Probability X Impact). Various factors should be identified in order to analyze risk, including:

Event: What could happen?
Probability: How likely is it to happen?
Impact: How bad will it be if it happens?
Mitigation: How can you reduce the Probability (and by how much)?
Contingency: How can you reduce the Impact (and by how much)?
Reduction = Mitigation X Contingency
Exposure = Risk – Reduction

2. Define your project. In this article, let's pretend you are responsible for a computer system that provides important (but not life-critical) information to some large population. The main computer on which this system resides is old and needs to be replaced. Your task is to develop a Risk Management Plan for the migration

3. Get input from others. Brainstorm on risks. Get several people together that are familiar with the project and ask for input on what could happen, how to help prevent it, and what to do if it does happen. Take a lot of notes! You will use the output of this very important session several times during the following steps. Try to keep an open mind about ideas.

4. Identify the consequences of each risk. From your brainstorming session, you gathered information about what would happen if risks materialized. Associate each risk with the consequences arrived at during that session. Be as specific as possible with each one. "Project Delay" is not as desirable as "Project will be delayed by 13 days."

5. Eliminate irrelevant issues. If you’re moving, for example, a car dealership’s computer system, then threats such as nuclear war, plague pandemic or killer asteroids are pretty much things that will disrupt the project. There’s nothing you can do to plan for them or to lessen the impact.

6. List all identified risk elements. You don’t need to put them in any order just yet. Just list them one-by-one.

7. Assign probability. For each risk element on your list, determine if the likelihood of it actually materializing is High, Medium or Low. If you absolutely have to use numbers, then figure Probability on a scale from 0.00 to 1.00. 0.01 to 0.33 = Low, 0.34 to 0.66 = Medium, 0.67 to 1.00 = High.

8. Assign impact. In general, assign Impact as High, Medium or Low based on some pre-established guidelines. If you absolutely have to use numbers, then figure Impact on a scale from 0.00 to 1.00 as follows: 0.01 to 0.33 = Low, 0.34 – 066 = Medium, 0.67 – 1.00 = High.

9. Determine risk for the element. Often, a table is used for this. If you have used the Low, Medium and High values for Probability and Impact, the top table is most useful. If you have used numeric values, you will need to consider a bit more complex rating system similar to the second table here. It is important to note that there is no universal formula for combining Probability and Impact; that will vary between people and projects.

10. Rank the risks. List all the elements you have identified from the highest risk to the lowest risk.

11. Compute the total risk: Here is where numbers will help you. In Table 6, you have 7 risks assigned as H, H, M, M, M, L, and L. This can translate to 0.8, 0.8, 0.5, 0.5, 0.5, 0.2 and 0.2, from Table 5. The average of the total risk is then 0.5 and this translates to Medium.

12. Develop mitigation strategies. Mitigation is designed to reduce the probability that a risk will materialize. Normally you will only do this for High and Medium elements. You might want to mitigate low risk items, but certainly address the other ones first. For example, if one of your risk elements is that there could be a delay in delivery of critical parts, you might mitigate the risk by ordering early in the project

13. Develop contingency plans. Contingency is designed to reduce the impact if a risk does materialize. Again, you will usually only develop contingencies for High and Medium elements.

14. Analyze the effectiveness of strategies. How much have you reduced the Probability and Impact?

15. Compute your effective risk. Now your 7 risks are M, M, M, L, L, L and L, which translate to 0.5, 0.5, 0.5, 0.2, 0.2, 0.2 and 0.2. This gives an average risk of 0.329.

16. Monitor your risks. Now that you know what your risks are, you need to determine how you’ll know if they materialize so you’ll know when and if you should put your contingencies in place. This is done by identifying Risk Cues. Do this for each one of your High and Medium risk elements. 

Monday, August 4, 2014

Dyman Associates Risk Management - Preparing A Risk Management Plan And Business Impact Analysis

The process of identifying risks, assessing risks and developing strategies to manage risks is known as risk management. A risk management plan and a business impact analysis are important parts of your business continuity plan. By understanding potential risks to your business and finding ways to minimise their impacts, you will help your business recover quickly if an incident occurs.

Types of risk vary from business to business, but preparing a risk management plan involves a common process. Your risk management plan should detail your strategy for dealing with risks specific to your business.

It's important to allocate some time, budget and resources for preparing a risk management plan and a business impact analysis. This will help you meet your legal obligations for providing a safe workplace and can reduce the likelihood of an incident negatively impacting on your business.

This guide outlines the steps involved in preparing a risk management plan and a business impact analysis for your business.

Saturday, June 7, 2014

Dyman & Associates Risk Management Projects: 75% of mobile security breaches will result from misuse

With use of smartphones and tablets on the rise and sales of traditional PCs on the decline, attacks on mobile devices are maturing, says IT research and advisory firm Gartner Inc.

By 2017, the focus of endpoint breaches will shift to tablets and smartphones. And, according to Gartner, 75 percent of mobile security breaches will be the result of mobile application misconfiguration and misuse.

Common examples of misuse are “jailbreaking” on iOS devices and “rooting” on Android devices. These procedures allow users to access certain device resources that are normally unavailable — and remove app-specific protections and the safe "sandbox" provided by the operating system, putting data at risk.

Jailbreaking and rooting can also allow malware to be downloaded to the device, enabling malicious exploits that include extraction of enterprise data. These mobile devices also become prone to brute force attacks on passcodes.

According to Dionisio Zumerle, principal research analyst at Gartner, a classic example of misconfiguration is improper use of personal cloud services through apps residing on smartphones and tablets. “When used to convey enterprise data, these apps lead to data leaks that the organization remains unaware of for the majority of devices," he said.

The best defense for an enterprise is to keep mobile devices fixed in a safe configuration by means of a mobile device management policy, supplemented by app shielding and "containers" that protect important data.

Gartner recommends that IT security leaders follow an MDM/enterprise mobility management baseline for Android and Apple devices as follows: ask users to opt in to basic enterprise policies, and be prepared to revoke access controls in the event of changes.
Users who are not able to bring their devices into basic compliance must be denied (or given extremely limited) access; require that device passcodes include length and complexity as well as strict retry and timeout standards; specify minimum and maximum versions of platforms and operating systems. Disallow models that cannot be updated or supported; enforce a "no jailbreaking/no rooting" rule, and restrict the use of unapproved third-party app stores.

Devices in violation should be disconnected from sources of business data, and potentially wiped, depending on policy choices; and require signed apps and certificates for access to business email, virtual private networks, Wi-Fi and shielded apps.
IT security leaders also need to use network access control methods to deny enterprise connections for devices that exhibit potentially suspicious activity.

"We also recommend that they favor mobile app reputation services and establish external malware control on content before it is delivered to the mobile device," said Zumerle.

Mobile security trends will be discussed at the Gartner IT Infrastructure & Operations Management Summit 2014, June 9–11 in Orlando, Fla.

Friday, June 6, 2014

Dyman & Associates Risk Management Projects Malware: How to Prioritize the Alerts

In late May, online security firm Trusteer, an IBM company, raised alarms about a new online banking Trojan it calls Zberp. According to Trusteer, more than 450 global banking institutions in the U.S., the United Kingdom and Australia have been targeted by this malware strain, which combines features from Zeus and Carberp, two well-documented banking Trojans.

Just days earlier, global cyber-intelligence firm IntelCrawler warned of new point-of-sale malware known as Nemanja, which had reportedly infected retailers in nearly 40 countries.

And news about recent evolutions in the mobile malware strain known as Svpeng also has caused concern. In May, Svpeng was found to have evolved from merely a banking Trojan to a malware strain equipped with a dual ransomware feature (see New Ransomware Targets Mobile).

But with so many alerts about new and emerging malware strains and attacks, how should banking institutions respond? It's a growing challenge for information and security risk officers because one of the keys to mitigating cyber-risks is differentiating new threats from older ones.

What's Real?

While banking institutions have to take all emerging threats seriously, they should take most alerts issued by security vendors in stride, says financial fraud expert Tom Wills, director of Ontrack Advisory, a consulting firm focused on payments innovations.

"It's mostly hype," he says. "Every time a new threat shows up in the media, this is the first filter I run. More often than not, there's a vendor or two behind all the excitement."

The influx of warnings from security firms about new malware strains has bred unnecessary concern for some banking institutions, says Andreas Baumhof, chief technology officer at malware research firm ThreatMetrix. In most cases, existing detection systems will raise flags, even when new variants of malware are detected on a network or believed to have infected an end-user's device, he says.

Pointing to the most recent announcement about Zberp, Baumhof says banks and credit unions should not rush out to invest in new detection and defensive technologies.

"There is nothing new for this Trojan," he says. Most banks' and credit unions' existing online defenses are equipped to detect Zberp and other Zeus variants, he contends.

Advice for Banking Institutions

Analysts recommend banking institutions maintain ongoing dialogues with their core service providers and vendors about the latest threats, and ensure they adequately vet new providers and vendors before signing on for service.

Among their other top recommendations:

Understand how existing detection and threat-mitigation solutions are equipped to defend the network. "There is no 100 percent solution, but banks need to understand their exposure and current capabilities before they rush to react," to alerts about new attacks, says Al Pascual, who heads up the fraud and security practice for consultancy Javelin Strategy & Research.

Put the onus on service providers and security vendors to send out notifications of possible risks, says Shirley Inscoe, a financial fraud expert and analyst for consultancy Aite.

Always get second and third opinions before revamping a system or solution. "Always get multiple bids, research the suppliers with independent parties, such as industry analysts and vendor-neutral consultants, and check with peers," Ontrack's Wills says.

Ensure the IT and security teams have strategies in place for comprehensive risk assessments. "Refresh it [the risk assessment] at least once or twice a year to keep it current - the more often, the better," Wills says. "That way, you can make sure that any solution you buy makes sense in the context of your own company's unique threat and vulnerability landscape, and not some generic landscape. It's quite easy to buy security products that you don't really need."

Thursday, June 5, 2014

Dyman & Associates Risk Management Projects on Threat intelligence versus risk

Security officers who view threat intelligence and risk management as the cornerstone of their security programs may have advantages over peers who face constraints when it comes to taking advantage of the available data.

CISOs are generally tasked with evaluating security controls and assessing their adequacy relative to potential threats to the organization, and its business objectives. Their role in cybersecurity risk management -- the conscious decisions about what the organization is going to do and what it is not going to do to protect assets beyond compliance -- is still hotly debated.

The transition towards risk management is more likely for the 42% enterprises whose security officers report to executives (the board of directors or chief risk officers) outside of the IT organization, according to Gartner. The firm's analysts advise security officers to achieve compliance as a result of a risk-based strategy, but admit that "organizations have not kept pace."

Equinix started to build a customized threat intelligence program about five years ago. The International Business Exchange data center provider uses threat intelligence along with risk assessment to do its "homework" before the company invests its resources in information security or agrees to IT requests from departments with different priorities.

"It doesn't make sense to go and buy a piece of [security] equipment because somebody in sales and marketing says, 'This is a big deal for the company,'" said George Do, global information security director of Equinix, which operates colocation centers in 15 countries. "We have to vet it, and we have to understand: Is this really a threat? What are the threat vectors?

"Sometimes, there is this black orbit, and we are just there for the ride," said Do. "I am always very conscious of that, and I want to make sure that whatever we are spending resources on is truly managing risk."

Metrics that Do reports up the chain of command, starting with the CIO, include data from the last quarter and year on the number of critical instances -- compromised data or critical servers, for example. Because Equinix employees frequently travel all over the world, security incidents, such as malware or backdoors, involving employees' mobile endpoints (laptops and mobile devices) are tracked, as well as employee acceptable-use policy violations.

In addition to capturing incident data, the security team tracks metrics around any attempted cyberattacks against the organization, especially around the perimeter from firewalls, VPN servers and mobile device gateways. "We have a Palo Alto firewall where I can see that [data] very clearly," said Do. "I can present a very simple dashboard to any executive that shows: Hey, at any given second of the day we are being attacked by literally thousands of threats and the firewall is doing its job so it's not like we invested in this for nothing."

While threat intelligence is the foundational piece of risk assessment at Equinix, the use of intelligence data in the security industry is often ad hoc. "It has either plateaued or actually decreased," said Do.

"There are always two sides of the spectrum," he continued. "The companies that are very good at doing SIEM [security information and event management] and all of these intelligence pieces so that the more intelligence or data points that they've added to their infrastructure, the smarter they become."

But the majority of the security teams don't do that. "They are either mired in compliance checkboxes or chasing down shadow IT services. Or there are so many things going on in their universe that there are no resources, or time, left to focus on threat intelligence."