Showing posts with label Resources. Show all posts
Showing posts with label Resources. 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, June 12, 2013

Robert Galambos Visual Resume



In the world where presentations can make or break a sale, a project, or a policy, I thought it would be a great idea to create something to showcase my MS PowerPoint skill set.

 Visual Resume

Monday, May 27, 2013

Musing of Big Data and Privacy

Big Data and Privacy. Or should a Big Box store figure out if someone is pregnant?  

Is that Private?


So what is Big Data? Is it the latest 'fashion statement' from the IT world? A bunch of numbers, letters, that represent something or someone? Something of an asset?

All the above and more. Basically it is the information, or data, that is generated by everyone and everything.  Examples of Big Data include this particular blog entered on the web, the decoding of the human genome, the buying habits for your customers, your credit score etc.

 Its 'stuff'. 
Google’s CEO Eric Schmidt stated: “From the dawn of civilization until 2003, humankind generated five exabytes of data. Now we produce five exabytes every two days…and the pace is accelerating.”

SO that is Big Data. But how does it concern privacy? Before we go there, lets reflect this issue. 

Companies are generating great mounds of data. Everything from what you purchase in grocery items (those Customer loyalty cards) to what credit cards you use and where. 

This is an asset to the company. It is something that can be analyzed, inspected, and reported on, all for the purpose to get the upper edge from their competitors,  a better understanding of the customers,how to market/target them to get the best results, What tickles their fancy so to speak? Maybe get that same customer to buy milk from your company as well as  the clothing that they buy now.

While doing the research for this blog I came across an interesting case study concerning this  issue.
A major Big Box chain’s (not Wal-Mart) department of thinkers (not a real department but could have well been named that) got together to try to see if they could 'predict' which of their  customers were pregnant. 

The reason was if they can get that pregnant customer to start buying the 'stuff' needed for the happy occasion, they could influence their buying patterns in the future. A better 'bottom' line (pun intended).

They had all this raw data about their clients and their buying habits. They can mine the information (Big Data) and determine if there were any patterns. And the results were, to say the least, eye opening. 

Now, this blog is not the place to have a detailed discussion about this, but needless to say the mathematical model that was developed was successful in more the 87% to predict, based solely on buying habits, which of their clients were pregnant. They were then able to target  the pregnant customers with  coupons, flyer's, etc in hopes getting them to buy more ‘STUFF’, 

This was done without the a client filling out a form letting the company know they were expecting, Ms Jane Doe customer had yet to buy a single diaper etc. The mining of this client’s information from the company database which indicated her buying habits, was the only determining factor. 
That is what Big Data is, and what it can do.

Can you see the issues in privacy in all this? Actually, there are really three different issues when dealing with Big Data.

Is what the company doing legal?
Is it ethical?
Is it acceptable to the general public? 
Let tackle the legality first. 
It’s not a simple answer. There are a lot of variables involved. Where does the customer live? Did he/she give permission to the company to use the data collected for internal (and maybe external) use? These are but two questions that privacy officers need to deal with, address and ultimately sign off on. 

Generally speaking, we can assume, when a customer signs up for a loyalty card, there would be some form of authorization to use the data. Or at least best practices demands such sort of disclosure, if nothing else. And this may be the easiest of the three questions.

Is it ethical? 

PHD theses have been written about this very question for 'years'. There is no gov't review panel to determine if it is or not ethical, but the question is still very valid.  One education site states that ' ethics refers to standards of behavior that tell us how human beings ought to act in the many situations..'  

http://www.scu.edu/ethics/practicing/decision/framework.html
While there is no stand fast rules on what is and is not ethical, one can, if for no other reason,  look into the mirror and ask the question? Is this ok?

Is it then acceptable? 

Going back to the story above, let’s see what happened. After the store created the model, they started sending flyer's, coupons that would target the would be moms. Examples, like diapers coupons , flyer's featuring cribs etc.  were sent out to the targeted group. 

Well, you can imagine what happened next. Many irate customers wondered, first of all, how did this company know they were expecting. Even more damaging to the company’s reputation was the fact that they were sending baby oriented coupons to non pregnant clients. And what if those target accounts were teenagers, and/or single,  and/or religious?

A public relations nightmare. In fact, while doing the research, I was surprised that this had not been thought out more thoroughly in the marketing department of the company.

All these factors play in the realm of Big Data. And privacy is just one of those factors.

Ultimately, the people responsible for privacy need to assure themselves that the use of the data is within legal constraints. 

It can be more complicated if that data  being analyzed is sent out to another company. There are 'mounds' of companies whose only job is to message the data and make sense of it. They can then market to those clients with targeted campaigns  as successfully as possible(the pregnant ladies from the above example), to get the best return on the data. (the Big Data).

Big Data means being able to see trends and patterns, not determining individuals buying habits per say. 

No one in Costco cares if the individual named Robert will buy a steak or a bottle of milk. What they do care about is influencing the group that Robert ‘belongs to’ so they can somehow how influence that targeted group to buy both products (as an example).  

 So an argument concerning privacy can go something like this:

Its not the PII information of a particular person that is being used (for the most part) for this type of analysis, but that a customer bought an item and he is middle aged, 6 foot, lives in a middle class area, Etc. And he belongs to a statistical group that represents 25% of the customer base in a particular region.

Maybe. But then again is that the only usage of these great mounds of data?

The debate on Big Data, how to handle it, and the ramifications on privacy will continue. What we need to do, is have the dialog, ask the questions, figure out what can and should be done. 

The concerns won't go away, and ignoring the issues will only make it worse.  We all need to first understand the issues and then try to make 'a go at it.' And at same time making sure we don't shot ourselves in the foot.


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.











Tuesday, April 30, 2013

Stakeholder/Privacy/Security Oh My



 


To continue with the theme I presented last time in which I discussed the differences between privacy (first pillar) and security (second pillar), I want to add a third pillar, that of the stakeholder. 

It seems obvious that he/she should also be included in any discussion along these lines. And yet stakeholders can only add complexity to the equation.  But before I begin, here are a couple of notes. I received a number of comments concerning the previous post. Some people commented about the fact that any discussion should include other interested groups as well. And as you will see, that is exactly what I will be doing here.   Yet I would be remiss unless I addressed another issue that was also brought up. 

What I 'd like to do, and only you, the reader, will be able to determine if I am successful, is to highlight the 'human' factor in this equation. As we move more and more to depending on, exploring, and exploiting the technology we use/rely on, we have had to develop tools to manage and control the reliance on the same technology. We have tools to check the code for security holes. We have tools to make sure we develop compliance processes. We have tools to help the auditors to verify systems, etc. 

Yet the one aspect that is forgotten in this mix is the human factor. He/she is the coder, the report writer, the auditor who verifies the results. etc. No system is fool proof and no human is perfect, except you the reader.   So why bring this up? I do so because some of the comments I received include the following: 'a security/privacy system that is put in place will address the wide divide between humans and technology/compliance'.

In response to this I say that tools are important, but we must realize that the tools are not the entire solution to this quandary. We need to understand entire eco system so we can successfully address the issues of Security, Privacy, Regulation, and Compliance. That being both the technology we use, and the tools we use to control/enhance it. 

So let's begin My objective in the previous blog was to highlight some of the inherent issues that prevail within the privacy/security domain. Here I want to explore the added complexity by adding the involvement of the stakeholder to this process.  Let define some terms. A stakeholder is the 'outsider'. The person who ultimately gains from the process being discussed. For a lack of a better way of definition, the owner/holder of the data in question. This can be a VP of the product line, the director of the stores, the sales manager etc. He/she is the one who can say, without question, 'the buck stops here". 

Generally speaking he just wants good end results. Most stakeholders see the added cost of implementing a well defined privacy policy/practice in place as an overhead that needs to be controlled. 

They want to make sure their data is safe but ask them if they think the added cost of security systems in place is, for example, worthwhile to prevent internal development personnel from having access to the real data, they would balk. (Note this is a generic over simplified statement, but I use it to make a point). To address this issue I point to a number of organizations that rely on non disclosure agreements (NDA)  the only protection to address the above mentioned issue. This is 'cheap' to implement and easy to maintain. Yet I hope you, the reader, understands that this solution is like having your teenager promise they will clean up the room. A good idea but without any other incentive probably doomed to failure.

The problem here is that we all have different views on the same situation. We come with different experiences, responsibilities, education. While the stakeholder is ultimately the person responsible (For further info along these lines read about the SOX act that was passed in the US), she/he may not know how a truly good governance regulation compliance (GRC) process is created. And in fact he might not even know why the company needs one in the first place.


So taking the analogy I used in my previous post(how security personnel and privacy professionals look at a 'square' and see it differently), the stakeholder is the owner of the 'square'. He holds the square but has no idea how it is constructed but only knows how the square is used, IE. not how the WEB application works. Only that a customer can sign in and order the widget.  So what can we to do? The answer I suggest is fairly simple. Education. 

The privacy officer must educate the interested parties. These parties include the stakeholders, the IT personnel Given that there is a privacy officer already in place means that the first step has been taken. The people who work on security need to educate everyone on what needs to done and what it takes to get it done.

The security personnel need to interpret the requirements and educate the parties on how this is implemented. Why does it extend the software development cycle. So in other words by educating the parties they can justify the time and materials that will be needed to produce eco systems that achieve the goals set out by all the interested parties within a manageable framework.

So to help the reader, I am suggesting a couple of different resources that can be used to help. 

1) A short piece on how to explain HIPAA to the layman (Stakeholder). It also provides some additional reading that may be of interest.

http://www.ehow.com/info_7778811_laymans-guide-hipaa-compliance.html

2) A very interesting website that targets NON lawyers with information concerning privacy. There are a lot of very good additional links that can be of some help. Please note that this site deals mostly with US laws.

http://www.eprivacy.com/lectures/toc.html#toc

3) Another good resource for educational purpose is the Electronic Privacy Information Center website. Once again, mostly US information.

http://epic.org/privacy/

4) On the consumer side of the debate, a list of resources can be found at 

http://www.privacyrightsnow.com/affiliates.htm

5) And finally, two studies that come out yearly. 

       A) One is the Telus security group yearly that looks at the state of Canadian companies security. It has 5 recommendations as well as pointers on how to try to make security more prevalent in the workplace. Registration is required.

http://promo.telus.com/securitystudy/

        B) The other one is the Verizon security's 2013 Data Breach Investigation Report. This report is a yearly report that encompasses expertise and information from various international organizations responsible for the reporting and investigation of data breaches. If you do not look at any  other resources listed here, then this is the one to read.

http://www.verizonenterprise.com/DBIR/2013/insider/



Please note the opinion of the individual authors/websites are their own, and I do not advocate, agree or dis-agree with the opinion expressed.
And this is just a sample of various resources that are available to help with the issues described above. But ultimately it is up to the individual to make sure they adhere to the best practices within their industry and Country.


Till next time

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