SAIJE Thoughts

Or “Minding the GAP(s)”

One of the items I notice a good deal is the extensive use of spreadsheets with Security Frameworks or Controls sets. The sad part is that there are so many tools out there that can better provide an overview of how well your organization is committed to Information Assurance and implementation of controls.In this post I am using Rational Requisite Pro and the NIST SP 800-53 as an example as I am a fan of the Open Unified Process (and Rational Unified Process by extension), but I am sure this method will work with any robust requirements management tool and framework/control set should you be willing to do the upfront work (or contract someone else to do it).

Within Requisite Pro, you have the means to track various types of requirements (such as Enterprise Requirements, Features and Supplemental Requirements). In my example, I use the NIST SP 800-53rev2 as a set of Enterprise Requirements. In other words, these requirements are applicable to all implemented projects in your organization. The document (or database should you use the database version of the NIST) is not in the proper format for importing into a Requirements Management Tool, so you need to either convert it into the proper format or find someone that may be doing the work for you already. In this case, I converted the NIST to a CSV table with the following key fields:

• Name – Name of the Control for Requisite Pro – eg. AC-2 : ACCOUNT MANAGEMENT
• Requirement Text – The text of the individual control – eg. The organization manages information system accounts, including establishing, activating, modifying, reviewing, disabling, and removing accountsThe organization reviews information system accounts [Assignment: organization-defined frequency, at least annually].
• Other fields – other fields that your Req. Management system uses are populated as well. I use Guidance extensively to add in all the supplemental information in the NIST Controls.

Each Control and Supplemental Control is listed as a discrete requirement.

Once populated, you now have a powerful means to implement controls, track projects, and even highlight projects that have gaps in their implementation.

Several Examples of uses are listed below:

1. Tracking your programs. Suppose you wish to Implement an Active Directory Project in your enterprise. You can now enter Active Directory as a subsystem, enter all the features you are implementing as Feature Requirements and then trace those to the Enterprise Requirements from the NIST. This will allow you to not lose sight of your goals, and also see what portion of the NIST Control set will be implemented with your project. Also, it will quickly allow you to see that there may be features you are missing. For example, you may notice that AC-7 Unauthorised Login Attempts does not is not traced from your Active Directory Feature set, indicating you have a gap in your project implementation.
2. Highlighting Gaps as part of your risk assessment. After entering your existing projects as subsystems and tracing their features back to your master Enterprise requirements, you can see what controls are not implemented. You now can fix your gaps by implementing policies, starting new projects, etc.
3. Issue an RFP to fix your gaps. Use the gaps as a requirements list for an RFP to hire a vendor and use the same list to evaluate vendor responses.
4. Highlight key areas. Using the attributes of each Enterprise requirement, you can prioritize your work. Standard Attributes for each requirement can include Priority (Critical, High, Medium, Low) and Implementation (Easy, Moderate, Difficult). This way you can see your critical needs and even prioritise them in order of difficulty. You can improve your security posture the best by selecting your Critical needs that are easy to do….
5. Features that do not have a Enterprise control that they can map to. This tells you one of three things. Either you have a feature that isn’t needed, you aren’t fully aware of which control it would trace to, or your Enterprise set is lacking. If your Enterprise set is lacking, then you need to perhaps add additional control sets to support your primary control set.

In summary, implementing your selected control set into a Requirements Management Program is a great way to track your information protection controls and ensure you are aware of and addressing existing gaps in your program. This will greatly enhance your information protection posture and may even help defending programs or prepare for Information Systems Audits at the management level.

Currently a Major Government Agency is implementing Requisite Pro in this manner using the NIST as a master list of Enterprise Controls. HIPAA Security Rules have been added as Business Rules that trace from the NIST control set, ensuring that all controls will be tracked over implementation of Information Security Projects.

For any questions, assistance on Rational Requisite Pro, OpenUP and/or information security controls, feel free to contact me. Ready to import templates of NIST and ISO standards for Enterprise Requirements in Requisite Pro can be made available, depending on your Enterprise Requirements Management Plan.

PAPER OR PLASTIC?

 We are starting to hear more and more about data breaches where credit card accounts are lost (hence the need to outline PCI Compliance). The most recent is the breach where 4.2 million credit card/debit card numbers are lost at Hannaford Grocery Stores (North East and their other chain in FL). Here is the basic article. Already 1500 known cases of fraud have occurred as a result of this breach.

While many are looking at the issues of how this happened and we may or may not ever find that out, a couple items stick out.

• Once the breach was discovered, it took about 3 weeks to fix. I understand there are technical issues, but essentially Hannaford weighed risks of shutting down credit operations vs the incovenience of fraud to its customers. Where do you think they stood?

• If Hannaford shut even the debit card operations (and still allowed credit), the risk would have been lower for its customers (at a loss of 1 - 1.5 % of the value of the charges and an inconvenience for some whose check cards for some reason cannot be used as a credit card.

Ever wonder why if you get cash at an ATM, they charge you up to $3.00, but to get cash back at a store, you get charged nothing? Or why in many places they make it more difficult to do a credit operation vs a debit operation? The answer is simple again- money. Stores are charged a percentage of the value of goods when running a credit operation (lets say 2%). When running a debit operation it’s a flat fee (around ten cents). In either case, the cost is passed to you, the consumer, which is why stores prefer debit. They can offer lower prices the more debit is used OR get a bit higher short term profit.  So they push debit operations by offering cash back operations and discourage credit by requiring signatures, paper slips, etc. So you may prefer using debit - it helps your store lower prices, but remember security. With debit charges, you are almost immediately responsible for the charges, whereas when the same card is used as a credit, your charges (and losses) are insured.

 In this case, it may be time to rethink debit vs credit for most people and use credit…..unless you want to go way back and pay cash or check. And also time to rethink stores liabilities once they discover a breach. The primary concern should be protecting the customer - in this case, when breaches are discovered, debit operations at a minimum should be suspended. Of course if the breach is due to negligence on the stores part, who ultimately pays for credit operatations will be in play between the store and credit corporations, but at least in some small part, a customer’s security is  alittle better. Yes, I realize that identity theft will still need to be monitored and more can happen, but at least your money is a tiny bit safer that way.

Simply put, in at least one area, response to the consumer, Hannaford failed in their corporate governance.

I can’t think of a witty title

Once you’ve determined the need for a SAS70 audit, the next key step is selecting an External Auditing Firm for your SAS70 engagement. The reason why you want this selection so early in the process is that this is not your typical external audit. In this case, the external auditor becomes a member of your team BEFORE the actual audit. They should help in determining the scope of the audit and the set of controls. Many detractors of the SAS70 audit state one of two things:

• A SAS70 audit is no good because the audited company determines their scope and controls so a lot is missed.

• A SAS70 audit is no good because the auditor only reports on what controls are present, there could be a lot that is missed.

By selecting an ethical and experienced SAS70 auditor, both these statements are false. While the company still is the final arbiter of scope and controls, the auditor as part of the team will highlight deficiencies in both places and can even include those items as part of the report. By doing this, your company will develop a stronger scope and set of controls.

Some may ask, “Why do this, it sets the bar higher?” That is a good question. Consider it like getting a degree. Not only does the degree count, but WHERE you get the degree counts as well. A Mail Order degree counts far less (if at all) as a degree from a certified institution. In addition, by having an auditor that is part of the team and has experience in SAS70, not only will you check the block in terms of customer needs, you also may improve your corporate operations.

 OK the short list of items to select an External Auditor:

• Must come from a CPA firm (or at least a CPA, but really you want  a firm)

• Should have several years at least of SAS70 experience.

• Able to provide references for SAS70 engagements.

• In their proposal, they should outline that they will help determine and/or review scope and controls or be part of the initial team before the audit period starts.  This addresses the issue I wrote about above and adds value to your SAS70.

• Should have some information systems and information security professionals on the team (CISA/CISSP/etc). While SAS70 is not a security audit, many of the controls selected relate to security. ISO 27001/2 (old ISO 17799) experience a plus.

• Must have Sarbanes Oxley auditing experience.

• COBIT experience/certification a plus.  (COBIT and ISO experience is good as these are common best practice control sets for IT Governance and Information Security)

Note that the selected auditor does not have to be the same external auditor you may already have on contract to provide services for your firm. In fact, many CPA firms may not qualify for the above items.

Obviously your company should interview more than one firm. In addition, finding the right firms to ask may be difficult. Search the web for firms. The big 4 all do these audits, but they could be cost prohibitive for smaller firms, many regional CPA firms also provide this service.  Ask other companies you do business with if they have contracted with an auditing firm for SAS70 engagements. Finally if you contract for third party services from another company (hosting for example), there is a good chance they have undergone a SAS70 audit and you may be able to find your auditor that way.

If all else fails, ask me, I have dealt with several reputable firms for SAS70 engagements.