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.

or Uncommon Sense was a Common Virtue

A recent post on Codinghorror.com having to do with misuse of data (appropriating user name and passwords) caught my interest.  In this case, a developer was offering a free piece of software to archive a user’s GMail account on to the user’s computer. By doing this, one could access one’s GMail offline OR restore GMail if somehow one’s mail was lost. The person using this software had to supply their username and password so the program could download the email which makes sense. This is no different than setting up any email reader. Unfortunately for the user, the developer of the software  put in his code a means to forward the user name and password to his own GMail account. It turns out over 1700 people had unwittingly given this user their email account password and username The software’s name is G-Archiver.

This falls within one of the simple tenets of social engineering. Offer something free (even if relatively useless) and people will give away personal information (user names, passwords, email and physical addresses, etc.)  Even more ironic is that by using normal email clients from reputable open source shops or software firms, one could download their GMail easily. In other words, this software that was downloaded for no cost provided no real value but preyed on users’ ignorance of what else may be available.

This also highlights a danger in Freeware/Shareware/etc. Without knowing what company you are buying from, one may never know what you are getting into. Freeware/Shareware from well known sources may help and, of course, buying software from well known companies may work as well. Neither immunizes one from people misusing personal information, but at least there may be some legal recourse or the company/group may have self-interest in protecting their reputation (and your data by extension). Finally, a lot of people use similar usernames and passwords for their email account and other systems. For those that haven’t thought about this, keep in mind that once someone has your email username and password, it may be very easy to access all your other accounts.For example - you receive a monthly banking account reminder in your email to www.mybank.com.  The person with access to your email account can now go to www.mybank.com and log in, trying the same username and password you use for your email access. If it works, on the bank site, they can get your bank account number and even authorise transactions.  For those users that think their bank account number is hidden (many websites only show the last 4 digits), just pull up your paper statement or a check image….If you think you’re safe because your password is different, all they need to do is have the user name (or in some cases even email address), click on forgotten password and the password is emailed to your account that they already have accessed!Lesson - never use your email address/user name or password for other accounts and make sure you know when you are giving your username and password. If you’re doing that right now, you may want to consider changing your ways…. Thoughts?