One of the most important characteristics of corporate software is response time (AKA speed). And it is quite difficult to achieve, since all corporate software solutions are multi-user, and operate on very large data-sets. Of course, everyone would like to have every action return instant results, but that's impossible. Here is a methodology by which a company should set application response time targets and evaluate the software against them.

Because delays in response at some if not all points in a software are inevitable, one should have a realistic stance about it. So, what is the required response time of an application? - It is the amount of time that the user CAN wait, not the amount of time the user WANTS to wait!

Here is a methodology to evaluate acceptability of software response.
The methodology has 6 distinct phases:


I. Identify which functions will be using this software. For the purpose of example, these functions use the evaluated software.

1. Customer Relations Management
2. Direct Sales
3. Service Provisioning

II. Identify activities in each function which will be using this software. Enumerate the actions performed by the above functions, and add a row with the following information for each action

• Function - The name of the function that is the owner of the action
• Action - The name of the perfomed action - as a busines activity
• #Times Per Day - Number of times this action is performed per work day by one employee
• Avg. Perf. Time - Average duration of each performance of action (in seconds)
• Des. Perf. Time - Desired duration of ech performance of action (in seconds)
• #Users - Number of persons performing this action during their work day

The filled table will show you what activities will happen on the software during a typical work day, and by how many people. This is essential for a realistic evaluation

The Avg. Perf. Time will give you the maximum expected response time, and the Des. Perf. Time will give you the optimal response time of the software for that action.

NOTE: You may want to reduce the received numbers by 25% for the evaluation, since all software packages tend to gradually slow down during usage, and this will give you breathing room. This reduction is a decision of the entire evaluation team and must be decided per project.


III. Identify the cutoff point for the test activities and acceptable variation of results - With the table properly filled, you have a set of realistic usage tests for response evaluation. Actually, the properly filled table will have a huge number of activities, so you need to set a cutoff point - which set of activities will simulate a real situation, but without going overboard.

Usually, you should discard actions that are infrequent (1-2 times per day) and don't have more then 5 minutes as Avg. Perf. Time, as well as actions that are deemed less important. This is a cruel part, and is best done with department managers

Also, you should define what is acceptable result. It is unrealistic to expect that the results will actually be 100% match to your targets. An example acceptable variation would be:

• at most 20% of the performed actions during the evaluation are above the desired response time but below or equal to the average response time.
• at most 5% of the performed actions s during the evaluation are above the average response time
  

IV. Prepare real amounts of data - A common mistake of the software developers is that they test their systems on a laboratory set of data, which is usually far from the real situation, both in volume and in quality. Evaluation should be performed using a copy of production data, possibly anonymized for security reasons.


V. Call in the testers and make the test - With the evaluation activity set and the data-set to evaluate on, hire a testing team to run the test. The best evaluation is the following:

• Runs an automatic test, run by programs simulating users, since they will measure the actual time of EVERY action down to a millisecond, and it's easy to analyze the results. To avoid errors, run the test at least 5 times, discard the best and worst results and average the remaining
• After this, run a test with real human users, and task them with timing and recording each of their actions. Then average the result of this test with the statistical results of the automatic test

VI. Analyze results and make a decision - In the perfect world, the result will be pass or fail and you will buy the software or move on. In reality, you will have great response times on some actions and horrible on others. And naturally, office politics and strategic interests will interfere with a cold decision. So here is a rule of thumb approach:

• If more then 25% of performed actions during test are above the respective average response time, return the software for complete reworking before re-evaluation
• If less then 25% but more then 10% of performed actions during test are above respective average response time, continue the activities of further evaluation or preparation for implementation, but insist on a re-test before final purchase to reach the expected acceptable variation
  
• If less then 10% but more then the acceptable variation of performed actions during test are above target response time, continue the implementation, but insist on a re-test before go-live to confirm reaching the target variation

Naturally, this methodology could be expanded and amended with other elements. But this version is quite capable of producing a very realistic results, very close to everyday working conditions under which the software will function


Talkback and comments are most welcome

The second Google Page Rank update of this year just finished a few days ago. Shortinfosec just received a great bump in rating - went from PR 0 to PR 3. Not too bad for a blog that's been around for 6 months!

Although the Google PR is increased, this was not the primary Shortinfosec's target. I am not writing for Google - I am writing for the readers. As long as the readers receive value, Google can choose to think whatever it wants about shortinfosec.

In the meantime, I would like to ask the readers the following questions

• Do you like the content on www.shortinfosec.net?
• What topics would you read about on www.shortinfosec.net?
• What would you change on www.shortinfosec.net?

Please leave a comment with suggestions (and praise if deserved)

A reader in the comments on our post Example - Bypassing WiFi MAC Address Restriction made the following comment

"# Obtain a valid MAC address that is allowed on the network - And that right there is the hard bit. Perhaps an article on that before declaring how easy it is."

First, I would like to clarify several things

• Every hacker attack requires some amount of specific knowledge, time, effort and resources. If this wasn't the case, they wouldn't have been called hackers, they would be called - everyone!
  
• it is not the goal of this site to provide step-by-step tutorials on actual hacker attack methods.
• The presented MAC Address restriction protection is very easy and it requires the least amount of knowledge, time and resources compared to bypassing other protection methods and attack types

Now, here is an explanation on obtaining the difficult element - a valid MAC address

• If the WiFi network allows for unlisted MAC addresses to associate and then uses some sort of egress filtering, on the router or service selection gateway, just assoicate to the network and run wireshark for 5 minutes to collect other MAC addresses on the network. Results in 5 minutes
• If the WiFi network does not allow for unlisted MAC addresses to associate, then you can
• Download Backtrack and burn it to a LiveCD. Backtrack supports most of modern WiFi laptop cards.
• Boot your laptop from the Backtrack LiveCD. Run Kismet, which will put your wireless adapter into monitor mode. Use airodump to collect packets for analysis and find valid MAC address - Results in around 3 hours
  
• Create a small Perl program to generate a cycle of possibly valid MAC addressess and cycle them on your WiFi card using macshift. This yields best results paired with a bit of social engineering - to discover the models of laptops connecting to the network, thus reducing the address space to search - depending on skills and preparation, Results in 4 - 24 hours

Related posts
Example - Bypassing WiFi MAC Address Restriction
5 Rules to Home Wi-Fi Security

Talkback and comments are most welcome

Among security professionals, it is a well known fact that using only MAC Address restriction is useless as a protection mechanism for WiFi. But for the general publiv, this is still a popular method. This post aims to show how easy it is to actually hijack someones MAC address and bypass this restriction.

Here is the process, as used on a Windows laptop

1. Obtain a valid MAC address that is allowed on the network
2. Download macshift, created by one of Internet's renaissance men - Nate True
3. Copy macshift.exe to c:\Windows\System32\
4. Find the windows name of your wireless connection, from the Network Connections, for example "Wireless Network Connection"
5. Open a Command Prompt(start->run->cmd.exe)
6. Obtain your adapter's MAC address, by typing ipconfig /all on the command prompt. The result will include the MAC address of all interfaces.
7. Type macshift VALID_MAC_ADDRESS -i "Wireless Network Connection". Here is an example screenshot.
8. Happy surfing

NOTE: Don't forget to change your MAC to it's original value when you are done!

The process without step 1 takes a total of 5 minutes. Now, it can be argued that it is not easy to obtain a valid MAC address, here are two scenarios:

• If the WiFi network does not allow for unlisted MAC addresses to associate, then you can :
  
• Put your WiFi card in monitor mode and capture some traffic - from there it is easy to find the MAC addresses
• Write a brute force program that will cycle the MAC address of your adapter and try to associate with the LAN. You can optimize the brute force by finding a laptop that can connect to the network and record the actual model. Then you can just cycle through half of the MAC address bytes
• If the WiFi network allows for unlisted MAC addresses to associate and then uses some sort of egress filtering, on the router or service selection gateway, things are much easier - just run a sniffer for 5 minutes and collect all other MAC addresses on the network. Filter out the gateway MAC, and at a later time (usually in the dead of night) try them one by one.

This example is presented just as an eye-opener to the readers with less security experience. MAC Address filtering may be used as a deterrent, but only with WPA2 encryption and minimal possible range of the WiFi access point signal.

Related posts
5 Rules to Home Wi-Fi Security

Talkback and comments are most welcome

Implementing an Information Security Management System within a company is not a simple process. But as all things, it needs to begin somewhere and the right place to begin is at the top.
All information security efforts should start with a strong top management commitment. This commitment is usually communicated via the Information Security Policy.

The Policy needs to be concise, easily readable by all employees and should clearly express the following statements:

• Management is very serious about Information Security
• All employees are responsible for and must enforce Information Security
• Operational responsibility and guidelines for the Information Security Management will be delegated to the named persons and via the named documents

The Policy should be an internal document, available and emphasized on the intranet and if possible on the public web site.

And if you think that by now everyone should have this done, think again. A lot of fairly large organizations don't have this document created and communicated. The freshest example is the City of San Francisco, which apparently did not have a proper policy in place.

Information Security Short Takes has prepared a Template document, that you can download and use as a basis for your own Information Security Policy.

Download the Information Security Policy Template HERE


Related posts
Template to Regulate your Firewall Configurations

Talkback and comments are most welcome

After the post on Example Business Continuity Plan For Online Business , there was a mail discussion with a reader about whether it's at all relevant to Blogs. Here I would like to stress a fact. The blog hosting providers have BCP plans, but to recover THEIR services, not all blogs. A lost blog may be collateral damage, since it is after all- free service.
Here is a Business Continuity Plan for Blogs - It is actually the BCP of Shortinfosec, which I am using

SHORTINFOSEC BUSINESS CONTINUITY PLAN BEGINS

Incidents

1. Loss of broadband link communication
2. Loss of Hosting (Blogspot down)
3. Loss of Hosting (Blogspot lost content)

Loss of broadband link communication
Time to wait before using BCP plan - 24 hours

• Find alternative communication alternative choice
• Use dial-up for connectivity - Time to achieve - Immediately
• Use public hot spot at the Mall or Cafe - Time to achieve - 1 hour
• Use GPRS from the iPhone
• Publish the following message, post in the hotlink spot and as a first post:

We are experiencing difficulties in publication of new content. We
will continue with publication within the next 24 hours. In the meantime, please review our Archive

Total time of minimal function recovery - 1 hour after BCP activation

Total time of full recovery - 48 hours after BCP activation

Resources

• Charged Laptop Battery
• Charged iPhone
• Modem within Laptop/PC
• WiFi adapter for Laptop
  

Loss of Hosting (Blogspot down)

Time to wait before using BCP plan - 6 hours

• Find alternative host and register - Time to achieve - 15 minutes
• Wordpress http://wordpress.com/signup/
• Typepad https://www.typepad.com/t/app/register
• Choose a default template and Browse to see that it works - Time to achieve - 15 minutes
• Login to feedburner and modify the feedburner path to new RSS feed - Time to achieve - 10 minutes
• Publish post with content below - Time to achieve - 10 minutes

Title: Temporarily Moved We are experiencing difficulties in hosting of http://www.shortinfosec.net/. We are
working to resume normal operation. In the meantime, this is our temporary
home.
Please send your comments, questions and reactions to shortinfosec _at_ gmail dot com

• Set-up the temp blog to accept the address http://www.shortinfosec.net/ - Time to achieve - 15 minutes
• Log-On to DNS Hosting and redirect http://www.shortinfosec.net/ to new blog location - Time to achieve - 15 minutes
• If the blogger problem persists more then 24 hours, post new content to new blog.
• Wait for Blogger recovery, and if required restore template and content so the original site is available.
• If blogger is not recovered within 48 hours, post old content as archive on the new site(PDF or backdated posts)

Total time of minimal function recovery - 80 minutes after BCP activation

Total time of full recovery - 48-72 hours after BCP activation

Resources

• Charged Laptop Battery
• Functioning Internet access (refer to incident 1)
• URL and account name/password of DNS Hosting Service - written down on paper, in laptop bag, also saved in laptop
• Current Backup of Blogspot XML Template - Backup Weekly and send as attachment to two web-mail services
• Current Backup of custom Widgets - Backup Weekly and send as attachment to two web-mail services
• Current Backup of Template Images and Icons - Backup Monthly and send as attachment to two web-mail services
• Current Backup of Blogspot Posts - Subscribe to Feedburner to two web-mail services - Immediate Backup
• Current backup of Downloads section - Backup Monthly and send as attachment to two web-mail services
  

Loss of Hosting (Blogspot lost content)
Time to wait before using BCP plan - 1 hour

• Login to blogspot or re-register if account is lost - Time to achieve - 15 minutes
• Choose a default template and Browse to see that it works - Time to achieve - 15 minutes
• Login to feedburner and modify the feedburner path to new RSS feed (if changed) - Time to achieve - 10 minutes
• Publish post with content below - Time to achieve - 10 minutes

Title: Temporarily Moved We are experiencing difficulties in hosting
of http://www.shortinfosec.net/.
We are working to resume normal operation. In the meantime, this is our
temporary home. Please send your comments, questions and reactions to shortinfosec _at_ gmail dot com

• Set-up the temp blog to accept the address http://www.shortinfosec.net/ - Time to achieve - 15 minutes
• Log-On to DNS Hosting and redirect http://www.shortinfosec.net/ to new blog location - Time to achieve - 15 minutes
• If required restore template and content so the original site is available.

Total time of minimal function recovery - 80 minutes after BCP activation
Total time of full recovery - 24- 48 hours after BCP activation

Resources

• Charged Laptop Battery
• Functioning internet access (refer to incident 1)
• URL and account name/password of DNS Hosting Service - written down on paper, in laptop bag, also saved in laptop
• Current Backup of Blogspot XML Template - Backup Weekly and send as attachment to two web-mail services
• Current Backup of custom Widgets - Backup Weekly and send as attachment to two web-mail services
• Current Backup of Template Images and Icons - Backup Monthly and send as attachment to two web-mail services
• Current Backup of Blogspot Posts - Subscribe to Feedburner to two web-mail services - Immediate Backup
• Current backup of Downloads section - Backup Monthly and send as attachment to two web-mail services

SHORTINFOSEC BUSINESS CONTINUITY PLAN ENDS

Related Posts

Example Business Continuity Plan For Online Business

Talkback and comments are most welcome

The San Francisco WAN Lockout incident is already written in the annals of IT history. I followed the development and the comments, and today i stumbled on a text Who is really to blame for the San Fran network lockout?. It does touch important issues, but leaves the white gloves on. So let's remove the gloves and point some fingers:

What was the situation?

1. Apparently, Mr. Childs was the only person with unrestricted administrative right to manage the network, supposedly because of the incompetence of the other members of the team.
2. The network is used to transport and manage all kinds of official documentation - including jail bookings and other law enforcement documents, payroll files, and e-mails
3. He created an authentication scheme where only he had administrative access on the network.
4. Apparently, the situation in points 1 to 3 was well know to the users and management, and was accepted as such.
5. Mr. Childs clashed with the new Security Manager on the subject of authentication and control, which led to poor formal review
6. The poor performance review and other undocumented power struggles led to the dismissal of Terry Childs and his subsequent arrest after he refused to relinquish the administrative passwords

Who's responsible?

• Terry Childs
• He played god and isolated all other network engineers from the network - thus preventing them from any chance to learn how to manage the network.
• He created and to date is enforcing the actual lockout that is the reason for all this ruckus.
• Terry Childs' direct line manager and the one level above
• They knew that Terry Childs had absolute control over the network and permitted that - If they were uninformed of the situation, they should be fired for gross incompetence.
• They did not create conditions for knowledge distribution and reduction of dependency on a single person (Terry Childs could have fallen ill or gotten in a car accident - they still need another engineer).
• They did not identify that there is a potential superiority problem with Terry Childs. This superiority problem usually manifests in insubordination when the control is taken away from a person.
• Poor human resource management - if all other network admins were so incompetent that administrative authority couldn't be given to them, why did they hire them?
• Top management
• They delayed or avoided implementing a security policy which Terry Childs would have had to obey.
• They did not create no single point of failure strategy for their personnel.
• Security Officer
• He did not identify a risk that the employee may cause serious problems and did not propose alternative workarounds - for instance - hire the equipment manufacturer professional services to regain control and lock-out Terry Childs.
• Entire line management
• Poor problem management - Once it became clear that it will be difficult to regain control over the LAN, they fired Mr Childs and called the cops. This only worsened the problem, since the cat is out of the bag, and the problem is still unresolved.

So, someone in the great City of San Francisco should now go around and actually look into the work of all named here, because incident caused by Terry Childs is just the effect, not the root cause!

Talkback and comments are most welcome

Yesterday Internet Security Systems (ISS) increased the Internet Threat Level to 2.

The reason for this increase is the publication of an exploit code for the DNS Cache poisoning vulnerability. Most of DNS Servers have this vulnerability unless patched with a recently issued vendor-specific patch.

Even with patched DNS servers, the threat remains under specific conditions

Details of the Threat can be read Here

Online based businesses are 100% dependent on IT services, but a lot of them don't even consider the scenario of what will happen in a situation of IT failure of the IT systems hosting their business/service.
Furthermore, a lot of online business owners simply rely that their hosting providers will recover their services -THIS IS WRONG - they will restore the information, but not necessarily functionality!
Here is an analysis and a summary plan for business continuity of an online business:

First, a couple of definitions:

• The goal of business continuity is to resume business operation in a reduced but controlled manner after a disaster which impacts operation - until full recovery is achieved
• The goal of disaster recovery is to resume IT operations after a disaster which impacts IT operation - until full recovery is achieved

Requirement analysis
For large companies, the initial step of planning business continuity is the Business Impact Analysis (BIA), during which the company identifies which processes are critical to the company's survival and need to be restarted immediately, and which can be restored later.

For small online portals/services these have the following processes:

• Service Delivery - actual service running on web and database servers
• Service Development - design, programming, upgrading, bug fixing of the service
• Sales and Marketing - promotion, communication with affiliates
• Accounting and back office operations - self explanatory

To simplify the BIA process, let's grade each process with a number by which we indicate which service process to be restarted at what time. Here are the numbers and their meaning:

• 1 - Process must never stop, immediate restart is needed
• 2 - We can survive without this process for 1 day
• 3 - We can survive without this process for 5 days
• 4 - We can survive without this process for 15 days

So, for our processes, these are the numbers

• Service Delivery - 1
• Service Development - 3
  
• Sales and Marketing - 2
• Accounting and back office operations - 3
  

So, the most critical process (surprise) is Service Delivery. This process is bound with network, hosting, servers, databases. Our continuity plan will limit itself to this process and only to one incident that can impact this process. The real Business Continuity Plan should take into account multiple incidents (power outage, DoS, loss of DNS, virus)

Example Business Continuity Plan

I. Incident type - Loss Of Application and Database Data due to hosting server errors
Steps to achieve continuity

1. Post a temporary information and contact page on alternative free hosting - Time to achieve - 15 minutes
   
2. Redirect DNS to temporary information page - Time to achieve - 10 minutes
   
3. Investigate whether servers are available. If not available, consult the list of alternative hosting providers that can provide hosting for 1 to 3 months - Time to achieve - 1 hour
   
4. Restore latest trusted backup of Database to operational DB server - Time to achieve -1 hour
   
5. Restore latest trusted backup of Web Application to operational Web server - Time to achieve -30 minutes
   
6. Perform functional test of updated infrastructure - Time to achieve - 1 hour
7. Redirect DNS to temporary information page - Time to achieve - 10 minutes

Total maximum time to recovery - 4 hours

Resources to achieve continuity

• Temporary page prepared and available for publishing
  
• Funds on credit card to purchase hosting for 1 month
• List of alternative hosting providers which can support the application with contact information
• Functional broadband link - alternative, direct access to hosting provider premises and vehicle for transport
• Database Administrator/Developer available for activities
  
• Web Application Administrator/Developer available for activities
• Trusted and Stable Backup of Database
• Trusted and Stable Backup of Web Application
  

Naturally, the plan must be tested that it works

This example plan is very limited (one process, one incident) but this is the general structure of a continuity plan. But for an online business, in which every second of downtime counts, such a plan may be the difference between a minor incident and loss of business

Talkback and comments are most welcome

Shortinfosec is hosting a computer forensics competition.
In the competition, you will have to analyze a submitted disk image for incriminating evidence, as per the scenario below

Scenario
The investigators suspect that the employee was doing the following illegal activities:

• Sniffing IP traffic on the network
  
• Creating back doors to his PC
  
• Stole and copied a CD-ROM with confidential content
  
• Downloaded copyrighted music
  
• Used a specific penetration tutorial document to perform most of his actions

The investigators found his PC turned off. They performed a DD copy of the surviving partition and sent it to you for investigation.

Competition materials
Download the evidence image here (compressed as hdb1-img.rar)

• hdb1-img.rar (rar compressed disk image containing hdb1-img.dd)
  
• Verification sum of hdb1-img.dd:
• SHA1SUM 60642d113d40cb583df0b0654cbc83ffca63f886

Rules of the competition

1. Each competitor should submit his summary report (indicating only the number of discovered evidence) as a comment to this post to establish time of solution.
   
2. Each competitor should submit a detailed description of the utilized process of to discover the evidence in an email sent to shortinfosec _ at _ gmail dot com.
   
3. All solutions must be submitted before midnight (CET) 20th of August 2008.
4. The ultimate goal is to find one incriminating evidence for each suspicion.
5. It is fully acceptable to submit a result with less evidence found, if you feel that there is no other evidence to be found or you cannot discover it.
   
6. The incriminating evidence may be disguised (renamed, compressed).
7. Each competitor can withdraw and resubmit a better evidence before the submission deadline
8. You can use any type of investigative tools that you need, as long as you maintain the integrity of all evidence (proven by a SHA1 or MD5 hash). The utilised tools must be documented in the detailed submission.

Reward

• Unfortunately, there are no financial rewards to this competition.
  
• The first competitor to discover all evidence or the competitor who discovered the most evidence before the deadline will be the winner. His result will be presented as an analyzed solution on Shortinfosec.
  
• Also, if the winner owns a blog or a site it will receive a separate detailed review on Shortinfosec.
  
• All other submitted results, regardless of discovered evidence will be published in the results as honorable mentions, with links to their respective blogs/sites
  

We hope to have a good and fruitful competition

Related posts
Tutorial - Computer Forensics Evidence Collection
Tutorial - Computer Forensics Process for Beginners

Talckback and comments are for the competition

In order to properly defend against an attacker, one should understand the profile and motivation of the potential attackers that stand against you. Here is a brief profile of persons that are against you (you can use these profiles in internal training)

Hacker wannabes

• Age - Younger teens, 13-17.
• Gender - mostly male
• Expertise level - After watching a lot of movies and knowing how to bypass the parental control on their browser, they like to think of themselves as hackers.
• Motive - They openly brag about their abilities and hope to achieve some social popularity through their skills
• Posture towards their skills - They openly brag about their abilities and hope to achieve some social popularity through their skills.
• Tools - In their actual hacking efforts they rely on howto's and "for dummies" books, and usually use prepackaged and downloaded attack tools to perform their "hacks".
• Organization - acting mostly individually
• Threat level - LOW - because they are employing standard prepackaged tools, even automatic defences (firewalls, IPS) will deflect such attacks. All it takes is an up-to-date protection system

Hackers

• Age - Older teens and young people (16-25)
• Gender - even distribution between both genders
• Expertise level - strong expertise in programming, TCP/IP protocols and operating systems. Regularly updating their knowledge through advisories and exercising on real or demo targets. Some posses good social skills (social engineering).
• Motive - Identifying vulnerabilities so they can be remedied. In certain cases, uncovering or making available to general public of corporate secrets for ethical reasons.
• Posture towards their skills - Very proud of their knowledge, and sharing with a limited group. They know the risks they take is present, since their targets may not always appreciate the efforts.
• Tools - Any number of off-the-shelf products always combined with custom written flexible code, viruses or worms.
• Organization - They tend to be organized in loose groups similar to guerrilla squadrons, but while the group works for a common interest, it's still every man for himself. Very often petty squabbles emerge in these groups and there is a large human resource rotation (some leaving, other joining).
• Threat level - HIGH - with broad knowledge and customized attacks, they can defeat some automatic defences (firewalls, IPS). Additional levels of protection are needed, regular patching, employee education especially against social engineering, as well as good audit trail log and review.

Criminal Hackers (crackers)

• Age - Varies from older teens to middle-age (17-45)
• Gender - even distribution between both genders
• Expertise level - strong expertise in programming, TCP/IP protocols and operating systems. Regularly updating their knowledge through advisories and exercising on real targets. Some posses good social skills (social engineering).
• Motive - Financial gain through crime or politically motivated disruption.
• Posture towards their skills - Very secretive of their knowledge, not sharing with anyone. They know the risk they take is large, and that should they be discovered their victims will go after them with a vengeance.
• Tools - Any number of off-the-shelf products always combined with custom written flexible code, viruses or worms.
• Organization - Can act individually or in an organized criminal group.
• Threat level - VERY HIGH - since they have criminal motives as well as broad knowledge and customized attacks, they will use multiple criminal vectors in parallel or to support each other. They will most frequently act as customers to gain access and trust and collect information on weaknesses. To protect against them, a full collaboration of physical and IT security is needed. Also, employee education and segregation of duties assist in mitigating these attacks.

Disgruntled IT personnel

• Age - Varies from young persons to middle-age (25-50)
• Gender - mostly male
• Expertise level - strong expertise in one area (programming, TCP/IP protocols or operating systems). Knowledge of other areas. Insider knowledge of systems and pass codes. Updating their knowledge of current infrastructure
• Motive - Financial gain through crime or dissatisfaction motivated disruption.
• Posture towards their skills - Skills are generally well known within the company. No effort to conceal them, since it's in their job description.
• Tools - All internally available tools for their everyday work, any number of off-the-shelf products always combined with custom written flexible code, viruses or worm