Tag Archives: IT risk

#5 – SUPPLY IT RISK MANAGEMENT GUIDELINE – NIST – SUPPLYCHAIN@RISK

Posted on by
Reply

A growing practice area is ‘Supply Risk Management.’  The challenge is that there are few standards and guidelines for managing supplier risk including supplier IT risks.

US National Institute of Standards and Technology has developed a guideline, NISTIR 7622, whose purpose is:

Federal agency information systems are increasingly at risk of both intentional and unintentional supply chain compromise due to the growing sophistication of information and communications technologies (ICT) and the growing speed and scale of a complex, distributed global supply chain. Federal departments and agencies currently have neither a consistent nor comprehensive way of understanding the often opaque processes and practices used to create and deliver hardware and software products and services that are contracted out, especially beyond the prime contractor.

This lack of understanding, visibility, and control increases the risk of exploitation through a variety of means including counterfeit materials, malicious software, or untrustworthy products, and makes it increasingly difficult for federal departments and agencies to understand their exposure and manage the associated supply chain risks. Currently, federal departments and agencies and private sector integrators and suppliers use varied and nonstandard practices.

Download the guidance document by clicking:

 

#3 – UNCERTAINTY & RISK BASED DECISION MAKING, JOHN PROHODSKY –

Posted on by
Reply

Uncertainty and risk are often used interchangeably, however, they are different.

Is understanding the difference between risk and uncertainty really that important?  Yes, especially when developing a management or project plan.  Risk is a known or anticipated event with an unknown outcome.  Uncertainty is an event that may not be anticipated.  A good plan includes mitigations for anticipated risks. Continue reading →

#3 – RISK CONTEXT IS EVERYTHING – CAROLYN TURBYFILL – TECHNOLOGY@RISK

Posted on by
Reply

Sometimes we get so lost in auditing jargon, technology buzzwords, heat maps and risk assessments that we forget common sense.  We also forget how quickly the future overtakes our state-of-the-art present.

The risk with respect to a resource or event can vary by location, year, day of the week, week of the year, time of day, acts of war or nature or even possibly by the ripples made by a drop of water (possibly the drop that causes a catastrophic overflow).  Perhaps your Tsunami wall was high enough except for the fact that the tectonic plate your island is sitting on dropped a foot in an earthquake.  A single failure can cascade into tragic disasters.

Today – you could have the latest, most secure, perfectly configured infrastructure for your business needs.  Tomorrow – you could be forced to connect your beautiful infrastructure to an unstable and insecure network (like the Internet) due to business requirements, a merger or acquisition, or ill-informed management executing a misguided vision.  Possibly you will be privileged to have visionary well-informed management with a funded vision and a realistic timeline.  Nonetheless, your equipment or some critical configuration will be rendered out of date by a patch, update, new business requirement or new technology.  How many companies are scrambling to offer their service on a mobile phone or update their infrastructure to securely support mobile phones?

One example of time-based context would be IT restrictions on a company internet at quarter close.  Login’s may be disabled for most staff after hours.  Web access may be restricted.  Phone calls may be monitored for leaks of quarterly results.  The network and equipment are the same, but the operating and business context change IT priorities.  The year 2000 was another instance of time-based context, where the world scrambled to update applications the original developers assumed would be rewritten or made obsolete years before the new millennium.

The most critical infrastructure (i.e. SCADA systems) may be most in need of updating and ironically, may be too critical to update.  There are applications on Wall Street that can’t be rewritten or ported because no one is quite sure exactly how they work.  The business rules are contained in code and institutional knowledge that departed with one or more key employees years ago.

Of course, I am writing this article with 20-20 hindsight with respect to beliefs about context that have been invalidated by unexpected or unlikely circumstances.  In reality, I have spent plenty of time with “umption” along with the donkey in “assumption”.