Thursday, 2 August 2012

None of the above!

We all like to believe the notion of a democracy. We have the belief that we exist in one and that the best choice is made to satisfy the most people.

The reality is far from this supposed “truth”.

Arrow’s impossibility theorem, the General Possibility Theorem, or Arrow’s paradox (Arrow, 1951, 2nd ed., 1963) demonstrate how the existing system fails. When faced with the choice of multiple parties, we cannot decide adequately on the end that will maximize the utility for the most people.

The result is one where we fall into a two-party system in default of the difficulties of choice. In place of having to create parties of people there to act for the majority, parties form with minorities. In the extreme, those such as the Fascists and Communists have managed to wield control and led to conditions of excess prior to the 2nd World War.

What we have now is a system that leads to a choice of second bests. There is no clear preferred member who stands, nothing placed by a party that could be seen as a majority, but it is one which is easiest to promote given a limited set of choices.

Why has this occurred you may ask?

The answer is simple. We cannot choose “None of the above”.

To create a true democracy, we need to have the option to select no candidate. These are people selected not by the population, but the parties. Those possible candidates who are acceptable to a majority of the voting public but not to those in power are excluded in the current system and this remains the flaw.

Only when we can say “No” to the choice we have imposed upon us and we can make the parties select the people WE want to lead us will we have a true democratic government.

References

Arrow, K. J. (1951, 2nd ed., 1963). Social Choice and Individual Values.

Tuesday, 31 July 2012

The Policy control framework

Policy is a control. It acts to set the rules and allows us to maintain standards. Without rules, there are few things we can really complain about.

To either assess or develop policy, they need to be set in a framework that allows for a structured approach to understanding and implementing issues individually. Start by developing a root policy (or top of the policy chain).This can be the mission statement, or can be based directly from a regulatory requirement or from legislation that the organization is required to adhere to. The framework can be different for different policies.

The framework derives from asking the question, "Is there higher level guidance outside of this organization that this organization should follow?" Next reflect on the overall security posture within the organization, the various levels of policies that already exist (if any), and the critical policies and procedures that both need to be in place and that have already been implemented.

Policy is the what. Procedure fills in the gaps allowing a how to exist.

Policy

A policy is typically a document that outlines specific requirements or rules that must be met. A policy is a intentional plan of action to guide decisions in order to achieve a desired rational outcome.

Policy is a formal, brief, and high-level statement or plan that embraces an organization’s general beliefs, goals, objectives, and acceptable procedures for a specified subject area. Policy attributes include the following:

  • Require compliance (they are mandatory)
  • Failure to comply results in disciplinary action
  • Focus on desired results, not on means of implementation
  • Further defined by standards and guidelines

Policy Levels

Policy should be a part of a framework. This starts with a high level policy that sets the overall requirements and should go into specific policy for individual issues that are faced by the organization.

High Level Policy

This is the document that guides the development of the policy framework. It should be authorized at board level (or as high as possible).

A critically task is the establishment of a security documentation baseline. The baseline is the foundation for evaluating the security policy for effectiveness and accuracy. Security documentation can be expected to vary across every organization(although several components will be similar).

High level documents such as a mission statement define what customers, suppliers, and employees should be able to anticipate from the organization

Issue specific and System Specific Policy

At the other end of the policy framework are those policies that are specific to a single system or issue.

Standard

A standard is a procedure or a set of specific requirements that must be met by everyone.

Information is one of if not the most valuable resource held by an organization. It needs to be protected. Standards need to be applied to all characteristics that are commonly associated with the handling of information and information systems. This needs to be done in a manner that is aligned to the Information Security Policy. A collection of minimum standards that must be applied when handing organization’s information assets should be developed in a manner that complements the security policy.

Standards can be depicted as a workable and generally specific statement of the expectations or controls that the organization has mandated. The objectives of an organization’s standards should be to define a set of requirements that are designed to end in the implementation of a minimum level of security for each information classification category. Standard should provide developers of systems with a minimum standard required to secure new and current applications.

The standards should be divided into the following areas of information systems:

  • General
  • Information Classification Categories

Guideline

A guideline is a collection of system-specific or procedural-specific recommendations for best practice, e.g., Microsoft Security Templates

A guideline is typically a collection of system specific or procedural specific "suggestions" for best practice. They are not requirements to be met, but are strongly recommended. Effective security policies make frequent references to standards and guidelines that exist within an organization.

clip_image002

Figure 1 Taken from “A Short Primer for Developing Security Policies” (SANS Policy Project)

Process or Procedure

Procedures are a control that is designed to ensure that the policy is effected. For instance, a procedure could set the controls in place that are designed to ensure that only those authorized to access a systems can do so. Procedures are a means of supporting the objectives of the security policy and a method of implementing it within the organization. Some procedures commonly defined within an organization include:

  • Procedures for obtaining access to a system and being issued a USERID and password;
  • Logon Procedures;
  • Procedures for password controls;
  • Procedures to handle incidents such as a security breach; and
  • Procedures to deal with malware (such as a computer virus or worm)

Ultimate Firewall

Marcus has a point as always. In the past the image from his blog was of the Ultimate Firewall. Now, it is the ultimate IPS.

Figure 1: The ultimately insecure firewall. It always fails.

That stated, I still have an issue with this.

The mentality is wrong.

Security comes as a juggling of three aspects:

  • Availability
  • Integrity
  • Confidentiality

The thing is, the CIA triad is generally best listed as the AIC triad for business. Even in the military, integrity of intelligence data means more than confidentiality (although we talk more of the C).

Marcus states on his page (tongue in cheek to some extent):

The firewall above is the only 100% guaranteed secure solution.

(* May have a performance impact on traffic if prevention is enabled)

Now, it is true this does have a performance impact.

Mostly, it negates the need to have anything in the first place. It reminds me of the NT 4.0 IIS server with a C2 accreditation. It is secure as long as it is not connected to a network. What use is a web server not on a network… Well it was secure.

Security is never an absolute. You can chase your tail forever, but you can NEVER make a perfectly secure system. Yes, you do get closer and closer to perfection, but each increment costs more and more.

It is sort of like trying to travel at light speed. In this case, the faster you are, the more you increase in mass and the greater the energy that is required for the next zero point closer. Well, it is the same with security.

The economics of security mean that we cannot ever be absolutely secure.

The formula to calculate risk are extremely complex and I will not go into these in this post, but the simple part of this is that for a given economic quantity, you get a set amount of security (in a given confidence interval).

This is better described as resilience and survivability. Both are terms used in systems engineering for a long time and which are sadly neglected in security.

What this means is that we have a trade off. 

image

Figure 2: The economics of security. It is always a trade-off

To make a system more available, we either sacrifice confidentiality or integrity. This is what I mean for a trade-off.

The other alternative is we increase costs. This makes the project less attractive. It lowers the IRR and maybe the project will not make the IRR (Internal rate of return) for the firm and it never occurs.

Here is the thing…

Business is all about risk. Nothing is perfect. It is about a trade-off.

There is not absolute state of security. The only thing we can do is to balance the economics of risk in a manner that makes the gains exceed the costs in the long run.

In thinking that removing a system from a threat makes it secure, we do everyone a disservice.

Only by knowing we are going to be compromised and accepting that systems are not secure can we start to train for what may occur. Only when we accept that we cannot make the perfect security system will we learn to deal with the inevitable breaches that occur.

Monday, 30 July 2012

Project 2010

Microsoft Project 2010 is a tool for managing projects. I teach this class at Charles Sturt University. The subject is MGI 513 

Enterprise Project Management. In this subject we look at the theory and practice in Project management.

Now, you may be wondering what a guy who specializes in Information Security and researches the economics of software and risk would teach project management. The answer is simple, most security incidents are projects. At least they should be if done correctly.

Operational issues such as patching are important, but an incident is a project. Any security consultant or manager worth their salt really needs to have project skills.

Video (Weeks 1-4) are about complete on this list (this is week 4 for my class).

The following are a list of videos on the web that will help you learn the hands on aspects of this course. More will follow. In my class we have weekly lectures, but we are also linking free resources on the web (as these offer additional study). These are what I have linked here.

I really do encourage anyone in information security to watch these and learn a little about project management. It may just make you more effective.

Week 1: A brief about Project Management Concepts

1.1 Understand Project Management Concepts

1.2 Understanding the requirements

1.3 Importance of Archiving Information

A Project Primer (http://www.youtube.com/watch?v=sPwURRG9_Gs&feature=related)

Week 2: Getting Started with Project

2.1 Managing Your Projects with MSP
2.2 Starting MSProject Professional
2.3 Exploring Views
2.4 Exploring Reports
2.5 Creating a New Project Plan
2.6 Setting Nonworking Days
2.7 Entering Project Properties

Critical Paths (http://www.youtube.com/watch?v=LsbnHNAkfVQ&feature=relmfu)

Week 3: Creating a Task List

3.1 Entering Tasks
3.2 Estimating Durations
3.3 Entering a Milestone
3.4 Organizing Tasks into Phases
3.5 Linking Tasks
3.6 Documenting Tasks
3.7 Checking the Plan’s Duration

Making a Master Schedule (http://www.youtube.com/watch?v=DvJIZ7lCEDw&feature=related)

Week 4: Setting Up Resources (Part 1)

4.1 Setting Up People Resources
4.2 Setting Up Equipment Resources
4.3 Setting Up Material Resources
4.4 Setting Up Cost Resources
4.5 Entering Resource Pay Rates
4.6 Adjusting Working Time for Individual Resources
4.7 Documenting Resources

An Overview (Part 1)

Week 4: Assigning Resources to Tasks (Part 2)

5.1 Assigning Work Resources to Tasks
5.2 Assigning Additional Resources to a Task
5.3 Assigning Material Resources to Tasks
5.4 Assigning Cost Resources to Tasks

An Overview (Part 2)

Week 5: Formatting and Printing Your Plan (Part 1)

6.1 Creating a Custom Gantt Chart View
6.2 Drawing on a Gantt Chart
6.3 Formatting Text in a View
6.4 Formatting and Printing Reports

Costing in Project (http://www.youtube.com/watch?v=N2-k941wL6Q&feature=related)

Week 5: Tracking Progress on Tasks (Part 2)

7.1 Saving a Project Baseline
7.2 Tracking a Project as Scheduled
7.3 Entering a Task’s Completion Percentage
7.4 Entering Actual Values for Tasks

An Overview (Part 3)

Week 6: Fine-Tuning Task Details (Part 1)

8.1 Adjusting Task Relationships
8.2 Setting Task Constraints
8.3 Viewing the Project’s Critical Path
8.4 Interrupting Work on a Task
8.5 Adjusting Working Time for Individual Tasks
8.6 Changing Task Types
8.7 Entering Deadline Dates
8.8 Entering Fixed Costs
8.9 Setting Up a Recurring Task

Week 6: Fine-Tuning Resource and Assignment Details (Part 2)

9.1 Entering Multiple Pay Rates for a Resource
9.2 Setting Up Pay Rates to Apply at Different Times
9.3 Setting Up Resource Availability to Apply at Different Times
9.4 Delaying the Start of Assignments
9.5 Applying Different Cost Rates to Assignments
9.6 Entering Material Resource Consumption Rates

Week 7: Fine-Tuning the Project Plan (Part 1)

10.1 Examining Resource Allocations over Time
10.2 Manually Resolving Resource Overallocations
10.3 Leveling Overallocated Resources
10.4 Examining Project Costs
10.5 Checking the Project’s Finish Date

Week 7: Organizing and Formatting Project Details (Part 2)

11.1 Sorting Project Details
11.2 Grouping Project Details
11.3 Filtering Project Details
11.4 Customizing Tables
11.5 Customizing Views

Week 8: Printing Project Information (Part 1)

12.1 Printing Your Project's Plan
12.2 Printing Views
12.3 Printing Reports

Week 8: Sharing Project Information with Other Programs (Part 2)

13.1 Copying and Pasting with Project
13.2 Opening Other File Formats in Project
13.3 Saving to Other File Formats from Project
13.4 Generating a Project Summary Report for Word, PowerPoint, or Visio
13.5 Generating Visual Reports with Excel and Visio

Week 9: Tracking Progress on Tasks and Assignments (Part 1)

14.1 Updating a Baseline
14.2 Tracking Actual and Remaining Values for Tasks and Assignments
14.3 Tracking Timephased Actual Work for Tasks and Assignments
14.4 Rescheduling Incomplete Work

Week 9: Viewing and Reporting Project Status (Part 2)

15.1 Identifying Tasks that Have Slipped
15.2 Examining Task Costs
15.3 Examining Resource Costs
15.4 Reporting Project Cost Variance with a Stoplight View

Week 10: Getting Your Project Back on Track (Part 1)

16.1 Troubleshooting Time and Schedule Problems
16.2 Troubleshooting Cost and Resource Problems
16.3 Troubleshooting Scope-of-Work Problems

Week 10: Applying Advanced Formatting (Part 2)

17.1 Formatting a Gantt Chart View
17.2 Formatting the Network Diagram View
17.3 Formatting the Calendar View

Week 11: Measuring Performance with Earned Value Analysis (Part 1)

18.1 Viewing Earned Value Schedule Indicators
18.2 Viewing Earned Value Cost Indicators
18.3 Generating an Earned Value Visual Report

Week 11: Customizing Project (Part 2)

19.1 Sharing Custom Views and Other Elements Between Project Plans
19.2 Recording Macros
19.3 Editing Macros
19.4 Customizing a Toolbar

Week 12: Consolidating Projects and Resources

20.1 Creating a Resource Pool
20.2 Viewing Assignment Details in a Resource Pool
20.3 Updating Assignments in a Sharer Plan
20.4 Updating a Resource’s Information in a Resource Pool
20.5 Updating All Plans’ Working Times in a Resource Pool
20.6 Linking New Project Plans to a Resource Pool
20.7 Opening a Sharer Plan and Updating a Resource Pool
20.8 Consolidating Project Plans
20.9 Creating Dependencies Between Projects

Review now

Sunday, 29 July 2012

SMART

SMART is a good framework for security policy and audit. It refers to:

  • Specific
  • Measurable
  • Attainable
  • Realistic
  • Timely
  • Specific

A specific goal has a likelihood of being success than a general goal. The questions used to create a specific goal require that you answer the six "W" questions:

  1. Who Who is involved?
  2. What What do you want to accomplish?
  3. Where Identify a location.
  4. When Establish the time frame.
  5. Which Identify requirements and constraints.
  6. Why Specific reasons, purpose or benefits of accomplishing the goal.

Measurable

Establish concrete criteria and metrics to measures progress toward the attainment of the goal. Measuring progress helps ensure that you stay on target, reach your defined dates, and achieve the goal.

To determine if a goal is measurable, ask:

  • How much?
  • How many?
  • How will I know when the goal has been successfully accomplished?

Attainable

When you recognize the goals that are most important, you begin to make them come true. You develop the attitudes, abilities, skills, and financial capacity to reach them. You start considering previously overlooked opportunities to ensure the achievement of your goals.

It is possible to attain nearly all any goals that are set when you plan each step and establish a time frame that allows the completion of those steps. Goals that seem far away and out of reach eventually end up closer and turn out to be attainable. This is not because the goal has shrunk, but due to growth.

Realistic

To be realistic, a goal must represent an objective toward which you are capable of achieving. A goal may be both lofty and realistic. Every goal must represent progress. A lofty goal is frequently easier to achieve than a low one as a low goals apply low motivational force. Some of the most difficult tasks to accomplish seem easy due to passion - they become a labor of love.

A goal is almost certainly realistic if you truly believe that it can be accomplished. Further means to knowing if a goal is realistic is to determine if you have accomplished a similar task previously. Alternately, ask what conditions would have to exist to achieve this goal.

Timely

A goal needs to be able to be completed in a set time frame. Without a time frame, no sense of urgency can be created.

T can also mean Tangible. A goal is tangible when it can be experienced with at least one of the senses. These can be, taste, touch, smell, sight or hearing. A tangible goal results in a greater prospect of making it specific and measurable and thus achievable.

The #security question du jour (ANSWERS TIME):

The following page is a good introduction to Nmap: http://linuxaria.com/article/understanding-nmap-commands-tutorial?lang=en

1. When would you use the –PR option for an Nmap scan?

The –PR option instructs NMap to perform an ARP (Address Resolution Protocol) ping scan on the desired target IP. This is a normal state for local scans and is faster on connected networks. In some instances, it can also be used to bypass poorly configured firewalls at layer 2.

2. List the most useful TCP ports to scan for in a network sweep. 3. What’s the Nmap “-F” command line option do?

We can answer parts 2 and 3 of the question in the same way.

A “-F” or – “Fast”, scans top 100 most popular ports. This is a means to get the most “bang for the buck” when scanning large networks and ranges. Basically, we are all time limited and we can add known bad ports we want to include to this list. You can also select “--top-ports [n]”. This option will scan the top ‘n’ ports. Ex 1000, 100, 50 ,etc.

I have also issued a number of posts on Nmap in the past on my blog:

http://gse-compliance.blogspot.com.au/search?q=nmap

Enjoy and test responsibly J