| Risk Management |
| Managing Risk |
In earlier steps, the measures of risk were quantified. Now what?
The business, knowing the quantification of the risk it faces, has three choices:
My role as a Risk Manager has required that I play "devil's advocate" when the first choice
(accepting the risk) is considered. Sometimes the cost or business pain experienced in
trying to fix a prospective fault outweighs the cost of experiencing the fault. I determine the
cost as a function of the Return on Investment (ROI): is spending $XXX to reduce the risk
YY% less than the cost of experiencing the fault $ZZZ? Sometimes cost is pure dollars,
sometimes it includes intangibles (reputation, good will, clients departing). Other times,
there are regulatory requirements that, no matter how insignificant the dollar loss, the
prospective fault must be lessened or removed entirely.
In Choice 2, taking steps to ameliorate through procedural and/or technical changes, I
have had significant success (see below) in thinking outside the box, upgrading Unix and
DBMS systems, changing procedures to vendors to ensure (telecommunications) port
safety, and introducing a series of Risk Management tools to enable the business
community to enumerate their risk profiles.
Distribution of risk, Choice 3, is often not given its due. Distribution can include insurance
against adverse effects (here we distribute the risk to other enterprises) which is often a
dollar-and-cents decision; we can offset concentration dependency by selecting
alternative products, vendors or logic (here we distribute the risk across various internal
entities); we can disperse a key-person risk by ensuring cross-training and proper detailed
documentation of tasks is current (here we distribute the risk across various resources).
The business, knowing the quantification of the risk it faces, has three choices:
- The business can accept that risk as a "cost of doing business", if the adverse event
occurs. - The business can take procedural and/or technical steps to ameliorate that risk.
- The business can distribute the risk in some way, so that the impact of occurrence of
the adverse event is lessened.
My role as a Risk Manager has required that I play "devil's advocate" when the first choice
(accepting the risk) is considered. Sometimes the cost or business pain experienced in
trying to fix a prospective fault outweighs the cost of experiencing the fault. I determine the
cost as a function of the Return on Investment (ROI): is spending $XXX to reduce the risk
YY% less than the cost of experiencing the fault $ZZZ? Sometimes cost is pure dollars,
sometimes it includes intangibles (reputation, good will, clients departing). Other times,
there are regulatory requirements that, no matter how insignificant the dollar loss, the
prospective fault must be lessened or removed entirely.
In Choice 2, taking steps to ameliorate through procedural and/or technical changes, I
have had significant success (see below) in thinking outside the box, upgrading Unix and
DBMS systems, changing procedures to vendors to ensure (telecommunications) port
safety, and introducing a series of Risk Management tools to enable the business
community to enumerate their risk profiles.
Distribution of risk, Choice 3, is often not given its due. Distribution can include insurance
against adverse effects (here we distribute the risk to other enterprises) which is often a
dollar-and-cents decision; we can offset concentration dependency by selecting
alternative products, vendors or logic (here we distribute the risk across various internal
entities); we can disperse a key-person risk by ensuring cross-training and proper detailed
documentation of tasks is current (here we distribute the risk across various resources).
| Professional Engagements |
Developed guidelines for Unix security lock-downs (various flavors of
Unix) and for DBMS (Oracle and Sybase), including scripts to check for
the lock-downs, to install lock-downs and to test business impact. Led a
team of 5 professionals in this remediation effort.
Unix security best practices were derived from DISA/DOD and Solaris
Security Kit (formerly JASS) documents, and were customized to the
bank's global environment. Emphasis included:
The database security best practices were derived from DISA/DOD,
Oracle and Sybase documentation course notes I developed while
teaching 'Concepts in Database Design'. Emphasis included:
Unix) and for DBMS (Oracle and Sybase), including scripts to check for
the lock-downs, to install lock-downs and to test business impact. Led a
team of 5 professionals in this remediation effort.
Unix security best practices were derived from DISA/DOD and Solaris
Security Kit (formerly JASS) documents, and were customized to the
bank's global environment. Emphasis included:
- access control and administration
- root activities
- scripts and cron's
- special purpose access modes
- logging and auditing
- special business requirements.
The database security best practices were derived from DISA/DOD,
Oracle and Sybase documentation course notes I developed while
teaching 'Concepts in Database Design'. Emphasis included:
- lock-down of default and guest access
- data dictionary protection
- use of principle of least privilege.
Developed a Unix-based telecomm port cross-reference to map
external vendor communication with ports with known port
vulnerabilities. This provided a consolidated view of client's risks as
potential vulnerabilities. Developed and executed plan for
consolidation of ports and minimization of risk, highlighting the most
vulnerable.
external vendor communication with ports with known port
vulnerabilities. This provided a consolidated view of client's risks as
potential vulnerabilities. Developed and executed plan for
consolidation of ports and minimization of risk, highlighting the most
vulnerable.
 |  |  |  |  |  |
| Major bank |
| Note that links are updated to represent the most current versions of the documents. |
| Major think tank |
| Major bank |
In developing a vendor management system, an interesting problem
arose.
The business unit representatives within the bank could be easily
authenticated since their communication was over an intranet and
had sufficient authentication services.
The problem is that surveys were being communicated out to vendors
over the Internet and the surveys were wide-ranging so that
information security, financial information, SDLC practices and other
disparate subject areas were asked. How to get the survey to the
single vendor-side liaison, get a series of parties on the vendor-side to
answer the disparate subject areas, get attestation from those people,
and get the survey contents back? All this AND the bank did not want
to become an administrator for employee names/id's of 1000+
vendors.
While the solution is proprietary, the major solution points included a
single-user digital signature, a group digital signature and one pair of
hinged chopsticks (the last is for laughs to see if you were paying
attention).
arose.
The business unit representatives within the bank could be easily
authenticated since their communication was over an intranet and
had sufficient authentication services.
The problem is that surveys were being communicated out to vendors
over the Internet and the surveys were wide-ranging so that
information security, financial information, SDLC practices and other
disparate subject areas were asked. How to get the survey to the
single vendor-side liaison, get a series of parties on the vendor-side to
answer the disparate subject areas, get attestation from those people,
and get the survey contents back? All this AND the bank did not want
to become an administrator for employee names/id's of 1000+
vendors.
While the solution is proprietary, the major solution points included a
single-user digital signature, a group digital signature and one pair of
hinged chopsticks (the last is for laughs to see if you were paying
attention).