Proposed Occupy Wall Street (OWS) Information Security Plan

Hippie Top Secret

Abstract

Information security is vital to accomplishment of the Occupy Wall Street’s (OWS) mission to facilitate a change in the current social, economic and political landscape. This document will provide a high level outline of specific security practices needed to ensure proper security controls are implemented to safeguard organizational information assets.

Introduction

The following policy will provide a high level overview of the organization security policy. Implementation of these controls will minimize risks and impacts of security incidents and will ensure that organization’s and member’s information is properly protected.

Access Control

Managing access to information and proper authentication and authorization of individuals is critical. Each member will be issued an identification card that will contain a picture and a small chip with an SSL certificate. The cards will require a 16 digit pin number to be activated. These cards will be required to access any information resource such as social media, intranet, OWS computers and other information systems.

Telecommunications and Network Security

Due to physical disparate network architectures, all members will be required to use Tor network client and then VPN into the corporate network. Juniper endpoint manager will be used to scan the connecting computer prior to connection and its settings will be configured for maximum security ensuring that no one’s computer is ever able to connect. This will provide additional cost savings by eliminating the need to purchase any additional VPN equipment.

Information Security Governance and Risk Management

A dedicated department of the most paranoid hippies will be established to develop organizational risk management strategy. All hypothesis, theories, news, delusions, concerns and fears will be taken as fact; no matter how unrealistic or unfounded. A risk management plan will be maintained to manage all of these concerns.

In addition, HR policies will incorporate mandatory background checks for all new personnel and members. Unless, the applicant has at least one felony and two misdemeanors, they will be automatically disqualified from employment.

Strict policies will be put in place to ensure cooperation of members, all personnel and work related communications will be intercepted, through mandatory internal software security package, and peer reviewed for signs of treachery. Access to employee’s social media accounts will also be required upon employment.

Software Development Security

Only open source and foreign software will be used on corporate resources. Several linguists may be necessary to translate the software to day to day business users. However, that is the only way to ensure that no government back doors are incorporated into the software.

Cryptography

All data at rest will be encrypted with AES symmetric encryption, all servers and mobile computers will require full disk encryption, as it works, someone will need to be present to physical reboot the servers every time. All data in transit will require 2048-bit encryption to ensure maximum security.

Security Architecture and Design

To facilitate overall secure architecture, all logs will be set to maximum logging and someone will go through them every day. To ensure nothing is missed, script parsing or aggregation will not be allowed.

Operations Security

All information systems will be patched daily; and only during core hours of 8 am to 5pm. No maintenance outside of this time window will be performed. Back-ups will also run during this time window to ensure the most up to date backup. In addition, all systems will be configured to run full daily antivirus scans, preferably starting at 9am.

Business Continuity and Disaster Recovery Planning

A disaster recovery and business continuity plan will be established. The business continuity plan will identify critical organizational functions and ensure adequate controls are in place for availability in case of a disaster. The business continuity plan will specifically focus on continuation of complaining and protesting after being evicted from public locations.

Legal, Regulations, Investigations and Compliance

All legal compliance will be taken very seriously! All member medical records will be immediately printed and stored in a huge safe, all digital copies will be deleted immediately after printing.

Physical (Environmental) Security

All facilities will be secured with a security checkpoint that will encompass armed guards, bomb sniffing dogs and polygraph detectors. Each person entering or exiting the facility will be required to present issued ID card, two other forms of picture ID and a biometric hair sample. In addition, they will be subjected to a search and a mandatory polygraph test.

In addition, the security checkpoint should always be understaffed, ensuring minimum number of persons pass each day. This will provide cost savings in procured office space.

Decisions

 

I got a good laugh out of this one and thought a lot of engineers can relate to Dilbert in this situation.

Original Dilbert page here:
http://www.dilbert.com/2012-05-26/

Installation Planning - Part 1

During the course of any project there will be a time when the system actually gets installed. This is a step in the overall roll out of a solution that generally lasts from a few days to a few months depending on the type of a system and number of locations being installed. By this time all requirements gathering, planning, system designs have been completed, socialized and approved. To be more specific, an engineering team is scheduled to go onsite to actually install and configure the software. 

A common mistake I see is the lack of documentation for this phase; usually it is a line item on a project plan with some high level milestones under it. From a project management perspective, that is all that is required to maintain visibility, however this lack of documentation can significantly hinder the project depending on the circumstances.

The solution is an installation planning document. I usually build these documents in excel and they have at least 6 columns. Task ID, Task Name, Task Notes, Assignee, Status and Time Spent. This turns into a list of steps that the system installer will need to perform to get the system installed. It needs to be as granular as you feel is necessary, I prefer to document each configuration file change, installation locations, ports, host names and paths for temp directories. I also like to add snippets of configuration files in the Task Notes column. Generating this document can be time consuming; however the content is re-usable and provides a great data set for estimating the schedule for future installations. 

Spending time generating these installation checklists are well worth the effort. There are some very practical engineering benefits. For example, in complex systems by generating the configuration files ahead of time, you may be able to spot certain issues with the configuration. These issues are much easier addressed if they are spotted prior to system installation.  

If you have multiple engineers installing the system, the checklist is a coordination lifesaver. Each engineer will know what they will need to do and having configuration files ahead of time ensures that all settings will match up and the system will operate when you turn it on.

There are advantages from the management standpoint as well. A key one is a peer review process, the installation checklist can be disseminated for review to senior engineers, architects and the system manufacturer. They may be able to spot issues with the configuration ahead of time or offer some improvement suggestions. This truly takes advantage of corporate reach back that so many large vendors claim they have.

Furthermore, this can actually decrease costs of implementation since the configurations can be developed off site by architects and senior engineers and the onsite installation can be performed by lower level systems engineers. Since all hard design work was completed ahead of time, the lower level systems engineers will not need to be as experienced. In this scenario the onsite installer can still call and reach a higher level engineer if trouble arises, but this frees up your architects and other corporate talent to work on more projects.

If the system is being deployed in multiple locations the installation checklist will ensure that the system installation methodology and configuration is the same. This will assist greatly if the maintenance of the system has to be transitioned to a different support group within an organization. Operations and Maintenance (O&M) will be a nightmare if each system is configured differently and planning upgrades will not be easy.

These are just some of the benefits of spending additional time planning the installation. In the next post I’ll share some techniques and tips on creating an effective system installation checklist.

Five CPE Credits for ISC2 - InfoSecurity

If you are an ISC2 certified security guru, you are required to maintain education levels through accumulation of CPE credits. One of the ways to obtain CPE credits is through magazine subscriptions.

InfoSecurity magazine is free and offers 5 CPE credits for the magazine subscription.

Apply For Free Subscription Here

Scalability

I think scalability is where true engineering takes place. Each vendor will have scalability documentation on how much load their product can support. These are usually conservative amounts so that they don’t promise too much. These need to be examined very carefully, since they will almost never provide you ALL the information you need, but are just a part of the puzzle.

Imagine that you are deploying a system for around 10,000 users. Out of these, there are perhaps 2000 concurrent users doing various tasks. The system will already have some data in it and new data will be coming in hourly. So you look at the vendor scalability documentation and it provides a case scenario of a 2000 user system, with 100 concurrent users doing one or two common tasks and data volume much lower than yours. Therefore, multiplying the environment in the scalability documentation would not provide you with the performance you are looking for.

This is mainly because, depending on the user actions, the bottle neck may occur in different system areas. Here is where the knowledge of backend technologies plays a crucial role. You will need to speed up the bottle neck areas and the only way to figure out how is through theory and experience.

For example, let’s say that during operating hours, a back end database like SQL is hard-hit and is causing a bottle neck. Instead of the common shotgun approach of upgrading hardware and moving to faster storage whip out performance monitor and start logging metrics. Windows Performance Monitor is a hugely underrated tool. It can provide valuable insight into many system performance issues. However, in this scenario, it would not be enough to determine which hardware component is causing the bottle neck. You would need to monitor specific SQL performance metrics to determine why the hardware component is causing the bottle neck, and then address the issue.

Going on with the example, you can run PerfMon to determine that hard drives are causing the bottle neck; it’s pretty common, since storage is usually the slowest part of the system. Drilling deeper, you can determine that the issue is due to constant reads from disks, at which point you can dig even deeper to see what the cache hit ratio is. If it is low, you can enhance the cache hit ratio to increase performance of SQL without necessarily upgrading hardware. You may also notice that some storage mediums are being heavily read, while another storage array is underutilized. In that case, moving the database or a few heavily read tables to that medium would also enhance performance.

Remember, various storage architectures are better for reading or for writing. It’s not uncommon to have different arrays for the same database server for different databases or even tables in the database. Impact of other components should be considered as well.

Furthermore, we can seek optimization outside of the bottle neck component. For example, let’s say that front end web servers are being heavily taxed. If the sessions are encrypted, it could be because of the large overhead for SSL and authentication. In this scenario, you can look into offloading SSL authentication at a different front end component such as an application delivery controller.

Don’t underestimate simple tools for purposes of scalability. A simple performance monitor and Microsoft Excel with the analytics plug-in is all you need in most cases.

Creatively scaling solutions is a dying talent because most of the time, people think it’s easier to just throw more hardware at the issue.

Solutions Engineering

So what is the difference between deploying a solution and a system? Sure, a system can be a solution to something, but deploying a solution has an entirely different scope of work. Deploying a system generally consists of having a few engineering sessions, going onsite to install it, doing some configurations, maybe migrating some data, training the customer and calling it done.

Deploying a solution is an entirely different ballgame and requires a different mindset from the client and the vendor standpoint. A solution will naturally have a system deployment component, but ultimately there are a lot of other moving pieces that contribute to program success.

Basically, there are a lot of other tasks involved in solution deployment to give the users a usable system that meets their needs. A prime example of this is training. In a solution deployment, you would not train users on the system; you would train them on the new business processing using the new system. Prior to training on the new business process using the new system, these processes would actually need to be re-defined, designed, developed, tested, deployed, vetted through user acceptance testing, re-designed and re-deployed and re-tested and re-vetted through users, etc… there is a lot of work involved.

Let’s go through a few differences on common deliverables between deploying systems and solutions. As a head up, I understand that all projects are different. It is certainly possible that some items from solution column bleed over to the system column. However, it’s important to acknowledge that when providing a solution you need to provide ALL of the pieces that make it complete. In other words, just because a system implementation has the project artifacts from the solutions column does not guarantee success. 

Deliverable	System	Solution
Technical Architecture	·         Hardware/Software Requirements ·         A few high level architecture drawings ·         Hardware is usually provided by the client	·         Hardware is usually included in the initial design ·         Environmental equipment such as load balancers, storage, networking, servers, KVM, UPSs are included in the design
System Documentation	·         System Manuals ·         Technical Support Number ·         CDs and License Keys	·         Installation Documentation ·         Configuration Documentation ·         Operations, Monitoring and Sustainment Plan ·         Test Plan ·         Migration Plan ·         Cut-Over Plan ·         Change Management Plan ·         Security Plan Project Documentation include: ·         Risk Management Plan ·         Training Plan ·         Communications Plan ·         Project Plan
Configuration	Only basic, essential configuration is implemented.	Specific to the client’s requirements.
Testing	Ensures the system and all components function as desired.	Tests the system under specific configuration of the client, usually involves load/stress testing, user acceptance testing, DR/HA testing, etc…
Change Management (Operations)	n/a	Perform change management to redefine existing business process to take advantage of new technology.
Change Management (IT)	Client makes any changes they want to the system.	Formal process for requesting, documenting, approving and implementing changes to the design.

Now that you’ve examined the list, I would ask you to reflect on your past experience with IT deployments and team members and ask yourself two questions: 

1)  Do you think some projects issues that you witnessed on previous projects could have been avoided by thinking in terms of a solution instead of a system?
2)  Who on the team is most suited to writing all of this documentation?

Most of this is Project Management 101; however, it’s very seldom implemented. Teams know that they should do it, but they choose not to, or the value of these artifacts is not stressed upon by the management. There is a lot of planning that needs to be done ahead of time for large solutions. This planning needs to be documented prior to system implementation. This does a few things, but one of the most important is that it creates the same expectation of the final product. This essentially defines

Change Management

In this context, the change management is not referring to user outreach, but change to project requirements, scope, system design and other project artifacts. Change management has a few faces depending on what phase of the project you are in. The further into the project you are, the more crucial it becomes. Basically, I see it as having a few main aspects 1) evaluate impact of change 2) notify everyone of the change so that they can plan accordingly.

To evaluate the impact of the change solid baseline for what the solution is needs to be defined through project and system design documentation.

·         Impact analysis - Without a formal process, you will not know the full impact of a design change. This is why a lot of projects finish late with costs that are higher than expected. The changes are incorporated into the project without proper evaluation.

·         Change control between groups – When multiple teams are working on pieces of solution, they all need to be in sync.

·         Requirements Changes – As requirements are added and/or change (and they will), additional time and money may be required to meet them. The impact of new requirements needs to be evaluated against the baseline to gauge the additional time and money required.