Showing posts with label implementation. Show all posts
Showing posts with label implementation. Show all posts

Tuesday, November 26, 2013

Small/Medium Business and Security/Privacy exploration










In this blog entry I want to explore the effects and the threats surrounding the small business realm and how it is effected by concerns of security and of course indirectly privacy.

But first some numbers.

1) Targeted attacks destined for Small  Business (1 to 250 (employees) accounted for 31 percent of all attacks, compared with 18 percent in 2011, an increase of 13 percent [1]

2) According to the National Federation of Independent Businesses, as many as 30% of an average company's employees do steal, and another 60% will steal if given a motive and opportunity.[2]

3) Almost three-quarters (72%) of data breaches investigated by Verizon Communications’ forensic analysis unit were focused on companies with less than 100 employees.[3]

And the list goes on. But I hope you get the idea.

In fact, depending on the source of data, there is no difference between the security issues of large organizations and small & medium business (SMB) (under 1000 employees).

Both types of businesses rely on computerize ‘everything’, to support their ongoing commercial and not for profit endeavors, never mind using social media for commercial marketing etc.. Both (large and SMB), for the most part, have web sites, use email, store information within databases containing commercial/proprietary information, financial positions (bookkeeping) etc. The employees also have access to various types of data (including those mentioned above), and can carry around that information on smartphones (bring your own device (BYOD)), etc.  Yet, except for some superficial attempt to secure the endeavor’s information, most SMB are vulnerable to threats like those that are mentioned above. The reason is because not enough is done to protect that sensitive information.


Let’s just investigate some best practices for organizations today.

All organizations, whether big or small, should have a Disaster Recovery (DR)/Business Continuity Plan (BCP) to enable them to still function and continue to be in business if an issue presents itself. How many small businesses do have a fully tested, functional BCP? Yet a disaster does not care if the company in question has 100 employees or 5,000.

All organizations should have and enforce internet/email usage policies. This should reduce any blatant misuse and potentially harmful activities of employees (or at least enable employers to take action if need be).

And the list of items that need addressing goes on and on. Many large organizations have specialist(s) whose entire responsibilities are just to ensure the day-to-day operation of the business.

While all organizations have to address critical issues, SMB have a number of strong disadvantages. The obvious one that comes to mind is their lack of resources. Namely most small business cannot afford a full time security/privacy professional. If money is not the issue (ever heard of a company where it wasn’t?) then a lack of expertise would be another major factor (and handicap). It takes time and experience to protect and recover from security concerns. And the basic human thought, ‘it will never happen to us, is something all personnel have to deal with.

So let’s take look at an realistic example of what can  happen to a $5,000,000 dollar a year SMB business.

11)    They have a major system failure and their systems were completely down for 4 days, and only partially in order for another six days. Total loss approx. $175,000
22) Cost to hire professionals to bring their system back on line $12,000
33)  Lost of a number important documents (payroll information, orders, A/R etc) that would be difficult to recreate. Cost unknown.

Total cost $187,000 +

Now lets take a look on the cost of setting up a relatively simple BCP/DR Etc

11)   Set up a working and tested DR/backup plan as part of a BCP $10,000
22)   Set up a commercial firewall, configured to help enforce the companies policies $10,000
33) Set up endpoint security (Anti-malware, Data Loss Prevention etc.) $5,000
44) Administration, training $5,000

Total cost $30,000

For a savings of  about $157,000 and with a big reduction of risk to the organization it then becomes obvious which of the two is the better option.

You can see by the numbers, the company in question would agree, it was a costly oversight not to do the due diligence, to say the least.

So we have all these organizations that are liable to have security/compliance/privacy etc issues, yet money is a huge concern. So what can be done?


There are a number of independent consultants whose specialty is to work with SMB. These consultants can plan and implement the best practices that are needed for an organization. They bring expertise, certifications, etc. that a small organization could ill afford to develop in-house due to the costs involved. For most SMB, once a comprehensive plan is developed and deployed, only a small additional cost would be needed moving forward to make sure everything is tested/working (maintenance/review changes etc) on an ongoing bases .

However, I would be remiss if I did not highlight the importance of finding a competent resource. There are a lot of consultants that have hung their shingle out to find business. So due diligence is in order. Ask for references, preferably with companies of a similar nature. Ask for any professional certifications that are concerned with this domain/realm. Ask for an estimate for the work needed. Get a Statement of Work (SOW) which should also include an established procedure for cost escalation and/or additional work requests. In other words try to make sure you are getting value for your money.


At then end it comes down to that, in our electronic world we work/live in, cutting corners will end up biting you on your bottom line. Ignoring the issues does not make it go away. But there is a reasonable way of mitigating those very real risks.

As the saying goes, ‘an ounce of prevention is worth a pound of cure’, and the sooner the better.




[1] http://www.symantec.com/about/news/release/article.jsp?prid=20130415_01
[2] www.nfib.com/business-resources/business-resources-item?cmsid=29624
[3] http://www.verizonenterprise.com/DBIR/2013/

Wednesday, May 22, 2013

Testing, in the black box (ATV), Security & Privacy



How Automate Testing Vehicles (ATV) should include Pentesting.

Why should privacy officers get involved in development, regression testing process?

Why does IT need to improve their testing strategies?

Pitfalls in Testing, Security/Privacy concerns is what drives people to have nightmares. Privacy officers need to have a better understanding of the environment they work in. The IT people need to embrace the notion that Privacy/Security starts from the beginning. So in that way the chances of being on a front page of a newspaper because of a breach and/or a failure will be minimized. NO ONE wants to phone the CIO about a problem like this. It is a team effort.

I do have to warn you, the reader, that some of the material may be a  little IT oriented. But in an organization where one needs to satisfy a number of different objectives, I would suggest at least a basic knowledge of the IT process is needed. And that the IT personnel need to understand the present compliance/regulator landscape.

Some definitions are warranted before I begin.

ATV or Automated Testing Vehicle. What is it? Why do I care? And is it a 'best practice'? (one of the most over used phrase at present).

The idea is fairly simple. Having a set of scripts (automated) that can be run to test the system in question. The objective is to test the system before any changes are implemented. The process should set up  the files that will be used for testing(see one of my previous blog posts concerning using data for testing),  then run the test scripts, and afterwards run the comparison reports and highlight items of concern from the test just executed. All this is done in an automated fashion. Rather simple concept, but one that can be 'processes' changing in a good way.

Well there is more to this. But let me define another term or two first.

IT systems that are down cost money in lost revenue, and good will to the enterprise.  As an example, in 2012 Google had an outage.
Google June 2012 down for 10 min.

The ball park figure cost that Google suffered was calculated at about $750,000. And that was for 10 minutes.  Now I am not suggesting all downtime costs are that much. It depends on the circumstances, but I am sure no one would like to find out for their own companies.

Another good example of the costs is sited at costs of web down time per industry

This site allows you to calculate the cost of a web site being down per industry/application. Its an eye opener to say the least.

In another 'word', downtime is BAD/EXPENSIVE *Yea  I know that is two words*. But joking aside we need to reduce unavailability as much as possible.

PenTesting. Wikipedia link  The Information Systems Audit and Control Association(ISACA) defines Penetration Testing as  "A test of the effectiveness of security defences through mimicking the actions of real-life attackers."

(For the reader who is more concerned with Privacy/Security, please read on)

So now let's proceed. When an application change happens IT personnel (or a designated organization) tests the changes (IE regression testing). They test the change to see if it works. Now depending on the process that is followed, a user may also test/approve the same series of changes to the application for user approval. Fine, right? Do you notice something missing in the above? In fact, there is more then one item here that needs to be defined/explored.

For many organizations testing to maintain the basic functions within an application does happen in a haphazardly way.  Sure the change is tested and to get to the enhancements, some basic functions are tested as well, But, based on my anecdotal experiences, on many occasions, the entire core functions of the changed application are not testing on a consistent bases.  A test of the all the basic core functions should also be completely tested whenever there is a change.

As an example, if the application in question is some public facing web application (a web store as an example), basic function testing should also be done. Test for example, the ability to add/change a Credit card information and make sure that the update still works. Test adding an item to the shopping cart etc.

So if the new function within the application fails, you have verified that the basic core functions, the one you need to keep the doors open, will still operate.

Imagine if an error occurs at your bank, yet the basic functions were tested successfully with the 'improved mobile bank portal' (the change that will be implemented).  Then logic would dictate that the basic functions should still work (you can still pay bills) even if the enhancement of the bank's mobile app does not. Corrections can be retested and implemented with minimal cost/embarrassment to the organization.

I am therefore advocating that there should be standard testing scripts that confirm, even with the changes that are going to be implemented,  that ALL the core functions still are accessible.

So to implement a process like this, you first need to map out the basic functions that you can not live without. Once that is done and scripts are created, an automated process should be created. When ready, a series of script can be executed with little human intervention. (less change for human error). The 'Best Practice' (there is that phase again) would be something along the lines of submitting the scripts and going home. When you get into the office the following day the results are ready for analysis/correction etc.

This should ensure that at even if the new change fails. You, the customer, can still do business with the organization in question. This is what some people call a ATV (see above). This process can be called your insurance policy.

However, lets' takes this further. Why just test  the basic functionality of the application? Should we also test for Security/Privacy issues?  Should the company's Privacy/Security office ensure that this type of testing, verification is also included within an ATV and executed whenever anything changes?

Absolutely!

A process that includes PenTesting (see above) is something one should consider adding to the above mentioned ATV. With any change there is always a chance that a vulnerability is created that may not have been there before.

Any failure can by it's very nature, cause the potential to expose sensitive information. It can be business secrets, and/or Personnel Identifiable Information (PII) to name but two potential headaches.

There is software in the marketplace that has the capability to engage/test/analyze applications for vulnerabilities. Some of the software I have previously mentioned as well as others which are available with the capabilities needed.

So I suggest that one creates an ATV process that includes the basic functionality of the application/system in question as well as additional testing for security/privacy. All  this should be automated so that more extensive testing can be executed as well as reducing the chance for human error.

Privacy officers need to ensure that any changes that are implemented will not cause exposure that may be costly. IT people need to make sure that the basic systems functions still run, no matter what is changed.

Finally, while no one can claim in absolute terms that there will be no issues, following these basic concepts can help reduce the chance that the CIO needs to be called because of an issue.











Monday, April 1, 2013

Data Privacy Project road map

 


 --> As I am sure most people agree, and have experienced as well, the majority of projects either come in over budget, late, or even worse, they never finish at all. A critical project like Data Privacy is no exception. But then again failure is not an option because of the consequences.

Before I begin, lets talk about privacy and the foundation of the project.

Politics. Yes I said it. And I am not talking about the govt type of politics, but the ones that all organizations have.

The first step that needs to be addressed is to get upper management sponsorship for a Data Privacy project. This is critical for the success of the project. Someone has to make the decision to bite the bullet to start funding and make sure that all department heads understands that  is mandated from the top.

This proposed project is  cost centered. It will not generate any revenue. It wouldn't make the widget run faster, nor get more customers. So getting funding for these type of projects is harder to get. One needs to make sure that upper management understand the business need, the ROI etc..

The data in question can span many applications which means many different departments are involved. A number of application owners are the stake holders in a project of this sort. So unless there is  someone high up giving directions, most likely roadblocks may appear that could be insurmountable.

This can be very daunting. I suggest that you start with a pilot project, unless you are in a small IT shop. Ideally choose a relatively isolated application, if possible. Start small to be able to learn where the road blocks/pit falls are. It is easier to learn from a mistake now then  to tackle more then you can chew.

Who owns the data? Who will decide how  the data be scrubbed? How much data will be scrubbed? Who will maintain the process once it is developed? These  will be questions that need asking.

Who will lead the project? What resources will be brought to bear on the project? Will the SME of the applications be used as reference, or will they be actually part of the project team?

Who will maintain the process after it is complete?

Ok, we can start, Right? Well not exactly. The next step is to determine  what 'methodology'/process/expertise will be used. Are you going to develop something in house? Or are you going to purchase something? The company may already have the tools  in place  that are capable to obfuscate data. Then all you have to do you is to deploy them.

The next item is determining what exactly needs masking/scrubbing. There are a lot of factors that need consideration. Some examples are, but not limited to, the PCI DSS standard (ie. if you retain/use Credit card information). If you have EU customers/locations/presence then one must be sure to adhere to the EU Privacy Directive. Or if you operate in Canada then one must make sure the company abides by PIPEDA, and so on. Most likely the answer to these questions will come from your legal, privacy or audit departments. So consultation is in order.

So we now have all our ducks in a row.  Like most IT projects there are basically four steps for a successful project. They are: analysis, design, coding and implementation, each building on the previous success.

The most critical step, is as you can imagine,  is the analysis. In fact I would expect that at least 50% of the time that you spend on  the project will be in this first critical phase.

Analysis.  In this first step your objectives are:

1 ) Identify all the data stores that have Personnel Identifiable Information (PII).

2) Take all the meta data and scan them for tell tale signs that they contain PII, for example a field that is labeled 'ADDRESS'. That in itself is not enough just to find those fields so named. You will also need to marry the meta data to the actual data store (where the data resides. ie. DB, flat files etc). This should be enough, but trust me it isn't.

The after these two exercises are finished, one needs to actually look at the data and see, if that ADDRESS field is actually PII. It could be the address of your branch office in which case it would probably not be PII, and outside the scope of the project.

Then there are the data field labels that do not reflect what is stored. An example could be a field that is labeled 'NUMBER'. This could be a phone number, a reference number, or the number of times the customer has ordered from your company. You will need to inspect the files, that you have identified (see above)  and make sure you  have a list of all the data fields, and the data stores that need obfuscating.

This is time consuming to be sure. But if the analysis is not done completely and thoroughly then the project is doomed for problems further down the road.

The results of this phase are a list of files that contain PII, and the fields within those files that need to be worked on..

Design. In this step your objective is to design the various techniques needed to obfuscate the data.

Taking the information developed in the previous step, a systematic approach will prevail.

You need to categorize the various data items that were discovered. For example, all the names should be grouped together and then masked the same way.. They all need to be masked the same way to maintain consistency and interoperability between the different applications. IE you need to make sure that Robert that is scrubbed to Oliver in application A. Then, if Robert appears in application B, it will also be scrubbed to Oliver in that application. This is crucial to the long-term success of this process.

The SME needs to determine the business rules that are applicable to the various groups of data. Are there edits on addresses to make sure that the masked address is located in the specified city? The birthdays of customers are important to be maintained because of insurance rates etc?

The masking rules that are being created against the various data fields need to take all business logic into account. And then to add to the complexity of the situation. the project team may be also be mandated to sub-set the data while copying from the production system. (see one of my previous blogs with a short explanation of various forms of testing that are normally inherent within an IT department).

In the next post I will continue to explore the design stage and then delve into the next two stages of Privacy project.

and as always if you have any questions drop me a line at

rgalambos@gmail.com

Robert Galambos CIPP/C CIPP/IT View Robert Galambos CIPP/C CIPP/IT VA3BXG's profile on LinkedIn