jump to navigation

Password Security, How Does It Work? February 27, 2011

Posted by Ishmael Chibvuri in I.T Risk Management.
add a comment

Don’t share credentials between your accounts, especially if security is your business.

I thought it was silly of Gawker Media to taunt world-plus-dog to test its IT security, only to be caught napping last year when its systems were compromised. But when your whole business is IT security, it’s even more embarrassing to be caught reenacting the tale of the cobbler’s children.

In that story, the cobbler was so busy making shoes for the village that his own children had to run around barefoot. This is—after being updated for the 21st century—pretty much what happened to security consultancy HBGary and its subsidiary HBGary Federal. From what I understand, one or more of the company’s executives thought that it was a good idea to use the same password for Twitter, LinkedIn and the firm’s content-management system. That became a problem after HBGary Federal’s CEO Aaron Barr decided that he was going to try to infiltrate the hacktivists collectively known as “Anonymous.” He was successful in doing so, but after revealing himself, apparently thought that his company was immune to retaliation.

But Barr’s sloppiness with passwords gave his enemies enough of a toehold to allow them to break into the consultancy’s e-mail server in early February and capture about 50,000 documents and messages. For the last few weeks, the two firms have been the butt of jokes, especially after HBGary posted a “pity me” sign in place of its booth at the RSA Conference in San Francisco.

Here’s the thing that makes this situation even more amusing than the Gawker debacle: HBGary was soliciting clients by letting them believe that its team knew better than to reuse passwords among key systems. (I’m sure that wasn’t actually in the pitch, but it was one of those things that you assume is there in much the same way that one assumes that a LAN uses Ethernet.) On top of that, HBGary had offered its services to Bank of America as experts in fighting back against WikiLeaks and in turn, Anonymous. This is the Internet’s equivalent of waving a red cape in front of a bull; do it enough, and you’re likely to be gored.

More likely than not, from some of the e-mail that I’ve seen that passed between Barr and one of his top coders, arrogance played a part in the debacle. The problem with the “can’t touch this” attitude is that it’s only valid while the people who want to take you down have better things to do.

I’m sure that the HBGary executives were thinking the same thing most of us do: “I’m kind of busy right now, and I’ll change it to something stronger when I have a little more time.” I’ve done that more times than I care to think about, as I noted in December when the Gawker story broke. Since then, I’ve become a little bit better at resisting the temptation to slap a quick and dirty password on an account. But I’m still doing it from time to time, as I realized the last time I ordered a cable from my new favorite vendor for such things.

I’m convinced that practicing password security in the fashion that many security experts say we should is just too much bother for all but a handful of people. “Easy to remember, hard to forget” only gets one so far if the password has to be rotated every month or two. Maybe we really are better off carrying around a piece of paper full of random characters with a few real passwords embedded in the randomness. This “poor man’s steganography” has to be a better approach to password security than what we have today.


IT Security & Network Security News February 27, 2011

Posted by Ishmael Chibvuri in I.T Risk Management.
add a comment

What does it take to get attention for IT initiatives in today’s enterprise? In most cases, according to Symantec Senior Director Jennie Grimes, it means making a compelling business case—and getting the right information to the right people in the right language.

IT risk management initiatives are definitely worthy of executive attention. Our economy is increasingly dependent on the Internet and IT systems, making the risks in these systems far more visible and significant than ever. But, it’s a discipline with a myriad of stakeholders: CIOs, CISOs, enterprise risk management teams, compliance and regulation staff, and internal and external auditors.

Step #1: Choose your words wisely
There are two types of CIOs—infrastructure managers and strategic thinkers. The latter will succeed with their IT risk management agenda because they speak in terms of business advantages, not outages.

For example, rather than talking about a “zero day threat,” consider simulating the impact of a potential incident in terms of potential business loss. Instead of talking about RTOs and RPOs, speak in terms of lost revenue and customers during an outage. Instead of highlighting unimplemented ISO controls, speak about the lost effectiveness of employees who need to share information both inside and outside the firewall. It also doesn’t hurt to point out the impact on productivity when employees can’t effectively share information effectively.  

Step #2: Use a High-Medium-Low spectrum of potential business loss
Part of using the right language is moving away from absolutes. Inevitably, a single prediction of loss will start a battle of statistics and probability debate and your request will get lost in the process. Instead, provide stakeholders with a variety of scenarios and have data to back it up. Consider whether you are a low risk company, moderately tolerant, or highly tolerant and then go to work with some calculations. Come prepared to back up your recommendations with numbers. Understand that you probably won’t get exactly what you are asking for, but by presenting accurate potential scenarios, you might get your mid-range goal.

Step #3: Use headlines to your benefit
Many of today’s business leaders dread the thought of the “orange jumpsuit retirement program.” There’s a steady stream of privacy and data leakage issues that will continue to make the headlines. Those held responsible have ranged from unsuspecting backup administrators to employees who unwittingly left laptops in car trunks to mid-level managers involved in publishing quarterly financial reports to executives operating with full knowledge of potential breaches. Make use of these “public hangings” to illustrate the real risks and move away from the incident probability statistic deadlock.

Step #4: Move your message up the chain (and sideways, too)
Consider all your potential champions and work to win them over. IT risk management isn’t an exclusively IT-driven discipline. Work with the compliance team, the IT group, the legal group, the auditors, the enterprise risk management group, and the business leaders. Create cross-company initiatives to align each of these groups. This requires as much time communicating outside of IT as inside IT.

Step #5: Identify your milestones
Before going in with your request, identify three milestones you expect to meet and explain in business terms how these milestones will provide returns to both the business and to IT.

For example, starting with a proof of concept for a content filtering project will have much more value if users from audit, legal and a line of business are involved in choosing terms to flag, track and quarantine. A security incident reporting process may get more enthusiastic response if users understand that increasing their awareness helps save corporate dollars and image.


IT risk management will become increasingly important as key organizational stakeholders begin to see the importance of an ongoing program. In the mean time, IT risk professionals can colleagues and establish a baseline program by using the right language and the right information to garner support internally.

Jennie Grimes is a senior director for Symantec’s IT Risk Management Program office.

Effective IT risk management February 26, 2011

Posted by Ishmael Chibvuri in Latest Articles!!!.
add a comment

Demystifying IT risk to achieve greater security and compliance.

Managing IT risk is part of running any business these days. Regardless of the business, understanding IT risk helps increase network security, reduce management costs and achieve greater compliance posture.

Failure to identify, assess and mitigate IT risk sets the business up for serious security breaches and financial losses down the road. And those that think managing IT risk is the job solely of the IT staff are in for a big shock.

Companies make considerable investments in people, processes and technology to ensure their businesses run smoothly. Understanding the relationships and levels of risk among these vital assets is imperative if you want to increase network security, streamline compliance and reduce overall IT costs. The challenge for most companies is to identify a repeatable process to identify, assess and remediate IT risk without interrupting their business activities.

Today’s IT risk environment is more threatened than ever thanks to the growth in sophisticated malware attacks and security vulnerabilities, with Web 2.0 adoption adding new layers of IT risk. Regulations continue to increase, placing additional costs on organizations to meet these new requirements. Organizations need an intelligent approach when it comes to assessing IT risk and managing compliance.

What is IT risk?

IT risk can be defined as any threat to your information technology, data, critical systems and business processes.

Management has a responsibility to identify areas of control weakness and respond in a timely fashion to these by improving processes, augmenting controls and even reducing the cycle time between control testing to ensure that the organization is properly identifying and responding to IT risks. However, labour and cost constraints mean you can’t mitigate all risk. There is always some degree of residual risk, either unidentified or known but unmitigated. The problem is that many organizations don’t understand that managing their IT risk — from the shop floor to the boardroom — is critical to business success. The inherent risks in IT show up in complex and subtle ways, making IT risk management a difficult concept to communicate and manage effectively.

By aggregating and reporting on the impact of security risks within IT and understanding how these risks impact the business, security professionals can become an integral part of business decision-making process and help guide the organization to a more risk-aware culture.

Is IT risk at the board level?

According to a 2009 survey of 280 audit committee members conducted by KPMG in conjunction with the National Association of Corporate Directors, IT risk is a key area of concern. Alarmingly, 45 percent said they are only somewhat satisfied with their oversight of IT risk, and 42 percent said they are only somewhat satisfied with the quality of information they receive on IT risks. This shows a significant gap in the communication of risks between executive management and IT.

It’s critical to the IT risk management process that executives are informed of threats and assist in assessing the business impact these risks pose, and sign off on the risk position. Only when the IT and executives are aligned in the identification, assessment and remediation of IT risk can a company achieve higher levels of security and compliance.

Here is a simple four step process model that can help elevate the IT risk conversation to the appropriate business executive, aiding the decision-making process regarding IT risk posture:

The first step is to identify and classify your IT assets down to which servers hold sensitive and confidential information. But, to determine which IT assets are most important, you need to first understand the core issues that concern the business stakeholders. Risks that need to be considered include:

* Data Confidentiality
The risk that confidential or sensitive information may be mishandled or made available to those who shouldn’t have access to the data. In many regions, protection of sensitive information is required by law and is also addressed on an industry-by industry basis through organizations such as the PCI Standards Council.

* Data integrity risk
This is incurred when the underlying data is unreliable because it is incomplete, inaccurate or otherwise suspect. The cause could be deliberate tampering or simple human error, be it improper error checking on form submissions or the inappropriate configuration of a transaction server.

Regardless of the cause, the impact to the business can be considerable, especially if the erroneous data is not discovered for some time. One of the most well-known IT risks in an organization is availability. The short term loss of service due to IT systems failure has the potential to have a significant – and potentially long-lasting – impact on the daily operations of a business.

* Relevance risk
This type of risk is rarely considered, but is one of the most common types we face. It has to do with not getting the right information to the right people, processes or systems at the right time. This often means that the right action is not taken or is taken too late.

* Project risk
Essentially, an investment or expense risk: the risk that an investment made in IT will fail to provide the expected value. Frequently, the real reason IT projects fail to meet their objectives is a lack of accountability and commitment.

So, what next?

First, identify your electronic assets. This requires scanning software that can inventory your network; non IP-addressable assets (such as people and processes) require automated surveys of the key organizational areas.

Second, map IT assets to specific business processes. By understanding what your organization is trying to accomplish in the marketplace, you can establish what systems sustain that value.

In other words, you must build a complete picture of how your IT assets correlate with your business functions.


Once you have identified your assets and the outstanding IT risks to the business you can then assign controls to them, and mitigate IT risk to acceptable levels.

The only way to effectively manage growing data points is through the proper use of automation which typically focuses on gathering controls data for audit support. This results in the ability to assess the environment more frequently and has two main benefits:

* Find issues before they escalate into full blown projects; thereby controls deficiencies can be remediated as part of daily operations, as opposed to project scale endeavours.

* Know where trouble spots are before the auditors arrive, demonstrating due care and that appropriate management controls are in place.

For too long, generating and providing reports to auditors has been treated as a disruption for IT operations. However, automation enables the production of meaningful and accurate reports specifically tailored to meet auditor queries. It also reduces the amount of time spent collecting data and reporting on IT controls, and instead allows the IT team to focus on how the organization can make best use of its regulatory environment.


A commonly overlooked part of the IT risk management process is the steps taken for remediation of detected deficiencies or vulnerabilities. There are three factors that mean organizations often have limited resources to address the risks they face every day – capital, labour and time. By prioritising IT work-based upon the business impact and risk tolerances, organizations can make the best use of these scarce resources.

IT security teams need to think like a “traditional” business and demonstrate how specific remediation activities (and even bigger project-level investments) will impact the organization’s IT risk posture; thereby giving value for every penny spent. By assigning a business value to the remediation work, IT can show how the IT security spending has improved the organization’s compliance and security posture.

Once a value is assigned to controls implementation and remediation activities, it must be tracked. Through consistent (automated) testing and reporting on changes made by the remediation efforts, the positive results of those activities become clear. Trends emerge that can be used to show the audit committee and other key stakeholders that you are exercising due care in responding to the shifting regulatory and threat landscape. In time, you can show that you are continually working toward a better managed risk programme.


The aim of the management phase is to make sure there’s a common goal of operational and strategic visibility in compliance, IT risk and control environments. The main requirement is to get to know your business’ numbers.

All businesses run on numbers; the trick to making sound IT risk decisions is no different. The first step is to find useful numbers that can be gathered (ideally in an automated fashion), the second is effective measurement, and the third is to communicate those numbers to the business.

For IT risk, it may seem logical to start with metrics generated by IT or information security; however, this is not the whole picture. Look elsewhere in the business to see the impact of IT operations and effective security and compliance activities. Using the numbers generated by those business units ensures that your success aligns with theirs. This way, metrics for compliance and risk management are received in a language the stakeholders can understand.

By frequently monitoring these numbers, you will have real-time situational awareness of compliance and IT risk processes. Long gaps in measurement can potentially undermine both the numbers’ validity and the security department’s credibility. That’s why it’s important to automate wherever possible to ensure that you are getting regular good quality data without overburdening staff or inefficiently using limited resources.

Frequent measuring of IT risk indicators allows the organization to spot trends, highlighting under- or over-performing areas of the enterprise. The organization can then target areas that are underperforming and remediate well in advance of an audit to show that management has insight into those areas and is exercising due care.

Once the data starts streaming in, continue to engage those parts of the business that have been tapped for that data. This showcases the value of high-quality IT risk management, and provides a phenomenal platform from which to grow your influence and involvement in guiding IT risk decisions and improving your organization’s overall risk posture.

By assigning a value to the metrics you are tracking, you can build confidence within the business for your IT risk decisions. When pointing out high-risk areas to the stakeholders it is far better to avoid selling ‘fear’. Instead, use solid metrics to build a stable base of credibility and business alignment that will pay dividends for years to come.


To effectively understand and communicate IT risk, the IT team needs to think and act like a business. By following this simple four-step framework, you can drive value in the IT risk management process for your organization.

Remember to keep these tips in mind when using the framework:
* Relate IT risks to business goals
* Utilise good numbers to support prioritisation and remediation efforts
* Report on those numbers and highlight trends to demonstrate continued insight into critical areas
* Keep the business engaged to create support and executive involvement

IT organizations can take the lead in identifying, assessing, remediating and managing IT risk when they use the right tools. The result of this allows companies to increase network security, reduce management costs and achieve greater compliance by effectively assessing and classifying IT risk.


Technology Risk Management February 25, 2011

Posted by Ishmael Chibvuri in Uncategorized.
add a comment


The objective of a technology risk management initiative for an Information Technology department is to identify applications that carry the highest technology risk, quantify it and provide necessary inputs into the operational risk management, business continuity, audit and architecture design processes within an organization. This will enable Technology Risk Managers (TRM) to define and implement plans to mitigate identified risk and provide visibility to senior namagement of identified risks, mitigations recommendations and remediation efforts.


The scope of applications selected for an initiative can be based on a number of selection criterias e.g. importance to the business, previous fraud incidents, outsourced components etc. This selection criteria can be decided by the Technology Risk Managers along with the Technology and Operating heads of the respective business lines.


* Different Forms are filled out by Application Managers of selected applications. The different forms are the Application Cataloging Form, Inherent Risk Form and the related Business Forms. A high level business process flow is shown here :Application Risk Management Process

* Scoring Results are collected and analyzed by the TRM and also forwarded over to other Process owners and Subject Matter Experts. (eg: BCP process owners, Information Security process owners) who requires the data for their processes.

* Mitigation areas and remediation efforts are agreed, planned and implemented by the Subject Matter Experts and or the Application Managers. The scores and remediation plans are updated in the Application Catalog.


Cataloging Forms – Applications in an organization have to be catalogued. These forms will help capture general information about and around applications. These form are usually filled by an application manager or someone he delegates to. A screen shot of the Application catalogue form is shown below. The list of forms will be available soon here.

Application Catalog Form

You can use the fields here to design your own internal database for cataloging applications which is highly recommended unless you have a vendor who provides this capability.

click here to download the application catalog form for free

Inherent Risk Forms – These forms capture Inherent Risk information for a given application. The information captured are aound an application’s availability, scale and volume, interfaces used, dependencies, etc. All this information is used to calculate the Inherent Risk of an application using a scorecard whose algorithm can be modified by the person maintaining the scorecard.

%d bloggers like this: