Spear phishing attack is a form of phishing attack which is aimed at targets with high authority and persons around them. By nature of their work, security procedures are disregarded or at least less respected in such circles, which can lead to significant security risks. Here is a quite realistic scenario for this attack.

The ShortInfosec Democorp CEO is away on business for the week. He has authorized his assistant to check his mail and handle responses as appropriate.
The ShortInfosec Personal Assistant reads an email from the chairman of the Democorp board to the CEO. The mail content is as follows:


The Personal Assistant sees that the mail is sent from the corporate e-mail address of Harry J and is formatted according to corporate standard. She knows that her boss will not read the e-mail for another 3 days.
So, she forwards the mail to marketing and sales, with the following text added:




Analysis

Within 15 minutes of receiving the original message, the directors of sales and marketing would have delegated the task to their subordinates and would have sent their documents to a Gmail address to which an unknown has access.
Here is what really happened:

1. The mail was originally fabricated by the attacker and sent from a open-relay SMTP, impersonating the President of the board
2. The names and official contact information of all relevant persons are available from the annual reports of Shortinfosec Democorp. If not, corporate e-mail format is standard and can be extrapolated by posing as a customer and exchanging several e-mails with other persons within Shortinfosec Democorp
3. The same method will be used to extrapolate the formatted signature at the end of the e-mail, as well as disclaimers or other standard corporate info contained in all e-mails.
4. An official conference agenda listed the Shortinfosec Democorp CEO as one of the speakers, so the attacker knows when he will be unavailable.
5. The WCI can be any relevant investment group, a name which can be identified from news clippings, or even invented - secretaries are not that much in the loop on large business decisions.

What should have happened

• The request to send confidential documents to a public email should have raised red flags.
• The Personal assistant should have called the President of the board to confirm the authenticity of the message.
• Also, she should have reported the mail as possible breach of procedures to the Information Security Officer and requested further instructions.
• Even if she disregarded all peculiarities of this email, the directors of sales and marketing and their subordinates should have reacted with a phonecall or alerted the Information Security Officer

In the real world, at the end of the day business comes first. So, the same material have gone to the Gmail account, but only after confirming that the president of the board requested it, and with maximum precautions

Result

An unknown person now has highly confidential corporate documents in his hands, which he can sell to the competition, publish, or extract information from them which will assist him to further his attacks.

Here are the controls that should be implemented to minimize risks of spear phishing

1. Implement e-mail digital signatures for all top management and key personnel, and set-up their laptops and PC's to automatically sign each sent message. Implement procedures that all unsigned messages received from these sources should be verified for authenticity
2. Perform regular training of all assistants and advisers to top management on Phishing and Social Engineering.
3. Perform regular but unannounced Social Engineering penetration testing on all assistants and advisers to top management, as well as all personnel handling highly confidential data
4. Educate top management with presenting results of penetration attacks to top to help them understand that breaching of instituted procedures can lead to severe security breaches - make this an exercise, not a power-point presentation
5. Advise all top management to accept and encourage the "when in doubt credibility of request, make a call" policy for their immediate subordinates, assistants and peers. Having a 1 minute phone call is much less fuss then a 100 page top secret report being leaked.
6. In case of real necessity to send such documents to public e-mail, provide fallback security procedures, for example: Send data as a Password protected PDF with a random password, wrapped in a different password protected rar file. Both passwords being communicated via another channel - sms or phone call directly to the president of the board
   

Related posts

Understanding Penetration Testing Methodology

TrueCrypt Full Disk Encryption Review

Hardware Security Module for Dummies

Personal Data Protection - Anonymizing John Doe

Talkback and comments are most welcome

Targets and metrics for information security are not easy to prepare. Most of IT and Security operations are based on maintenance, and they are dependent on a large number of outside factors. Here is an example on how to approach the problem.

Last week Shortinfosec.net reached the 1000th visitor. Although it is a ridiculously small number for a serious site, I ask all readers to be patient, since this site is alive for only a couple of months, and it's more of a hobby.

What is important for is to measure performance and set targets. And the only way to do that is to do establish metrics and update them. The current ShortInfosec.net target is to increase the total monthly visits by 100% each month. Here are our monthly statistics (courtesy of sitemeter.com).


Targets and metrics are not always easy to prepare, especially in information technology. Most of IT and Security operations are based on maintenance and are dependent on outside factors. Another thing is that targets are very difficult to set if metrics are not measured to establish a baseline.

So, what to measure? Here is a simple rule set of choosing Information Security metrics

• Measuring must be a continuous process. If there are gaps in your measurements, they are useless for analysis and for setting targets
• Identify what to measure. This can be done via two approaches:
  
• Define list of objectives which you want to reach and identify which metrics are needed to measure the achievement of these objectives. This approach focuses on the relevant objectives that need to be observed, but usually it is more difficult to measure all necessary metrics.
• Define list of metrics that can be measured and define which objectives can be concluded from them. This approach focuses on measurable metrics, but the observable objectives may not be entirely relevant to the entire process.
• Delegate responsibility for measurement or set-up a system that will automatically measure and log all relevant data
  

Here is an example of a very simple measurement process for an Information Security Management System

The Information Security Manager identified that the following metrics can be collected:

1. Number of reported incidents within the quarter
2. Number of critical incidents within the quarter
3. Number of identified risks in audits, controls and risk analysis within the quarter
4. Number of identified critical risks in audits, controls and risk analysis within the quarter
5. Number of identified attacks within the quarter

Upon request of the CEO the Information Security Manager identifies the objectives that can be extrapolated from these measurements:

• Riskiest business areas - based on metrics 2 and 4, the areas with most critical risks can be identified
• Employee awareness - based on metric 1 and 3, security awareness can be evaluated based on the number of reported incidents.
• Company exposure - based on metrics 2, 4 and 5, the security exposure of the company can be evaluated

Targets are set as follows

• Number of reported incidents - should increase or maintain level in each next evaluation period
  
• Number of critical incidents - should decrease in each next evaluation period
  
• Number of identified risks in audits, controls and risk analysis - should decrease in each next evaluation period
  
• Number of identified critical risks in audits, controls and risk analysis - should decrease in each evaluation period
• Number of identified attacks should decrease in each evaluation period

Of course, this example is not flawless. The reader should see points for improvement, and apply additional metrics to reach objectives.
I would be very happy to discuss any example scenario sent by the readers to the comments

Talkback and comments are most welcome

Every company has the responsibility to organize and perform penetration testing (pen-test) of its premises and systems at certain intervals. However, few companies understand the process of penetration testing and rely on the supplier to provide all direction. Here is a brief description of a penetration testing methodology, that should aide the security officers in managing the actual test.



Definition

A penetration test (pen-test) is a controlled process in which a trusted third party performs security verification by using methods, tools and styles that would be performed by persons with malicious intent.



Elements of the pen-test



Target - a resource which will be targeted for attack during the pen-test. The target can be a single item (server, router, safe) or a set of resources with some common denominator (server farm, network segment, offices)



Trophy - a resource that the testers are tasked with extracting or destroying. Malicious attackers usually stand to gain benefit from the attack, and if the valuable resource is identified, it can be tagged as a 'trophy' to be won by the pen-testers. Bear in mind that sometimes the trophy may not be a physical item, but a loss of functionality or service that can tarnish the reputation of the company.



Test vector - the attack channel or set of channels that the pen-testers will use during the test.



Test type - which type of test will the pen-tester perform.

• Black box - the pen-tester performs the attack with no prior knowledge of the infrastructure, defence mechanisms and communication channels of the target organization. Black box test is a simulation of an unsystematic attack by weekend or wannabe hackers (script kiddies).


• Gray box - the pen-tester performs the attack with limited knowledge of the infrastructure, defence mechanisms and communication channels of the target organization. Gray box test is a simulation of a systematic attack by well prepared outside attackers or insiders with limited access and privileges.


• White box - the pen-tester performs the attack with full knowledge of the infrastructure, defence mechanisms and communication channels of the target organization. White box test is a simulation of a systematic attack by well prepared outside attackers with insider contacts or insiders with largely unlimited access and privileges.

This element differentiates from what kind of malicious attackers is the company trying to protect itself. Each next test type is not a super set of the previous one. For proper penetration testing, one has to perform all three types of test.



Process

The penetration test must be approved by top management, with proper signed decision. The decision to perform a pen-test and it's details must be maintained as highly guarded secret which is known only to the top management, the security officer of the company and internal audit.



The supplier of the test (pen-tester) must be a credible and trusted company with relevant experience. Prior to top management approval, the supplier must provide a detailed pen-test plan to be approved by the the security officer. This test plan must include details about

• the target


• the trophy


• the test vector (locations to be tested, sources of pen-test attack like phone numbers, ip addresses etc.)


• the test type (white, gray or black box)


• names and references of all persons that will perform the pen-test to be approved by the buyer


• list of tools and methodologies that will be utilized during the pen-test


• method of protecting any collected confidential information during the pen-test


• method of self-auditing the entire pen-test process


• method of buyer-auditing the entire pen-test process


• time period of the pen-test

This test plan when approved will be amended to the pen-test contract, which should also include the following:

• A clause for penalties for any damages caused by the pen-test, which should not be higher then the contract value, except when malicious intent is proven


• A clause for risky test approval in which the buyer will approve or disprove possibly risky tests. Should such tests be approved, a list of targets and tests must be included.


• A clause to confirm that there is no conflict of interest by any involved parties in the penetration test. This clause should include or be amended by full industry affiliation of all involved parties.


• A clause of full confidentiality - restriction on using the results of the test for commercial purposes; restriction on publication of references regarding the pen-test; full and utmost protection of all information, results and conclusions collected during the negotiation, preparation and pen-test regardless of existing Non-disclosure agreements.


• A clause of immediate full disclosure - all collected results and conclusions must be reported in detail, regardless of estimated severity. Each conclusion must include tools and process description used to reach the conclusion. All conclusions estimated as critical and severe must be reported as they are identified in the pen-test, and the full detailed report must be handed over in maximum 48 hours days after completion of the pen-test.

Audit

Since the penetration process is a controlled process, it must be subject to immediate and later audit. This can and should include

• on-hand surveillance of the penetration test as it is performed


• filming the entire process on video camera


• full packet capture on all interfaces through which the penetration test is performed

Finally, here is a diagram of a penetration test process




NOTE: That this description is too brief to provide a full pen-test methodology. It is however based on a OSSTMM 2.2 (Open-Source Security Testing Methodology Manual), which i recommend to be read by everyone. However, this document is much more helpful to penetration testers.




Talkback and comments are most welcome

A standard practice in software companies is to put the new hires, often not properly trained to productive work as soon as possible. This practice is an understandable business requirement, but if not controlled properly can lead to bug creep or unwanted complexity in the code.

In my experience as a software developer, i can name hundreds of situations where poor code caused days of debugging or corrections.

Here is one, very simple example:

When creating an array of data in Java, one uses a constant for the array dimension. When using the created array for sorting, or searching through the content of the array, one creates a FOR cycle, starting with 0 and ending with the constant number size of the array.
What will happen when a user requirement demands the extension of the same array? A programmer (usually one that has wronged the project manager) gets assigned to changing all values of the array size in the entire code. This will probably be a couple of days very very of tedious work.
If the initial code used the length method of the array in each FOR cycle instead of the constant size value, the entire change will be only to the constant used to create the array. Suddenly, this becomes a 5 minute job (which you can still charge 2 man days to the customer).

To sum up, here are the 3 rules of keeping attention to detail and good programming practices in your companies

1. All software companies have a document named 'Development Standard' or 'Development Conventions' or the like. This is the new hires' bible of work, and everyone should check that the new hires know and understand it before putting them to work on a commercial piece of code.
2. The Development Standard document should not be written once and forgotten. Mandate a regular standard review and upgrade by your best and most experienced developers, at least once a year.
3. For good measure, amend your Development Standard with the latest edition of a good book on your programming language of choice. Things get forgotten, and this will provide a fast refresher course material for your developers.

NOTE: This post was written by a guest blogger - Marija Spirovska, currently holding position of senior developer at a multinational software company.
ShortInfosec thanks for her contribution, and hopes that she will continue to contribute to this site.


Related posts

8 Golden Rules of Change Management
Application security - too much function brings problems
Security risks and measures in software development
Security challenges in software development

Talkback and comments are most welcome

I have received comments via e-mail that my posts are not supported with enough examples. To remedy this, ShortInfoSec is creating a fictional company ShortInfoSec DemoCorp -
http://democorp.shortinfosec.net

DemoCorp will host diagrams, sample procedures and policies on the topics that ShortInfosec will be discussing.

The goal of DemoCorp is to provide a set of blueprints and examples that system designers, engineers and managers can use when creating, developing or upgrading their infrastructure

Please bookmark our new subdomain, and visit it as often as possible. New items will appear on a daily basis

Talkback and comments are most welcome

A lot of people using the free MS SQL Server 2005 Express hit a brick wall when they try to import data into the created database. Here is a tutorial, with video demo included on how to use the command-line BCP tool to import data into MS SQL Server 2005 Express.

During an analysis i conducted in the past days, I also found out the hard way that MS SQL Server 2005 Express does not have a GUI based Data Transformation Services. The only thing it does have is a BCP command-line tool.

So, here is a step-by-step tutorial how to use the BCP tool and not give up on an otherwise good (and free) product:

1. The data - I am importing data collected by tcpdump. I stored the data into a CSV file (data.csv), a text file with a comma delimiter.
2. Here is a sample row 16,10.176.1.105,NULL,10.176.1.254,NULL,NULL,64,17.12.2007,19:20:52,520,PING Req,NULL
3. Creating the database - Log-in with the command-line sql tool (sqlcmd) and use the following set of commands to create the database and table for storing of imported data:
   

• sqlcmd -S ATLAS\SQLEXPRESS
• create database data_analysis
• go
• use data_analysis
• go
• create table data_import (
• [No_packet] [int] NULL ,
• [Src_Logical] [varchar] (255) ,
• [Src_Port] [varchar] (255) ,
• [Dest_Logical] [varchar] (255) ,
• [Dest_Port] [varchar] (255) ,
• [Flags] [varchar] (255) ,
• [Packet_Size] [int] NULL ,
• [Packet_Date] [varchar] (255) ,
• [Absolute_Time] [varchar] (255),
• [Additional] [varchar] (255) ,
• [Protocol] [varchar] (255) ,
• [newdata] [varchar] (255)
• )
• go

Content verification - To verify the contents of the created table, use the following set of commands

• use data_analysis
• select count(*) from data_import
• go
• quit

Data import - To import the data, use the following command

• bcp data_analysis.dbo.data_import in data.csv -T -C1250 -c -t, -S ATLAS\SQLEXPRESS

Detailed explanation

• bcp - the executable file name
• data_analysis.dbo.data_import - name of database, owner and name of table to receive the data
• in - the same command is used for export and import. in means importing, out means exporting
• data.csv - file name that contains data to be imported, or to receive exported data when using the out direction
• -T - swich indicating trusted connection. When using this switch, the bcp command uses the kerberos ticket of the logged-on Windows user to authenticate. If you don't use -T, you'll have to use -U and -P (user name/password)
• -C1250 - collation. I found out that BCP does not work well with Unicode files, so i am forcing the 1250 collation (central European) - works with most characters
• -c - treat everything as characters. This way it will be very easy to import any information.
  
• -t, - delimiter. Default delimiter for BCP is tab, so i need to inform it of my delimiter character (comma)
• -S ATLAS\SQLEXPRESS - server. This switch is followed by the hostname\instance name (for MS SQL Server Express its SQLEXPRESS)
  

Content verification - To verify the contents of the created table, use the following set of commands

• use data_analysis
• select count(*) from data_import
• go
• quit

Here is a video clip of the entire process



Related posts

Personal Data Protection - Anonymizing John Doe

Talkback and comments are most welcome

A reminder - The second issue of the Information Security and Strategy Carnival ShortInfoSec is coming on the 1st of June. Please submit tests on the following topics:

• information strategy
• information security
• network security
• database security
• data security
• vulnerability analysis
• penetration testing

As established, the carnival will be published on the 1st day of every month. We will accept only original texts, which present a strategic opinion, review of event or product, or a HowTo on a relevant topic.

Please send submissions by the 25th e-mail:
shortinfosec _at_ gmail dot com
or submit them through the Blog Carnival Web Portal http://blogcarnival.com/bc/submit_3975.html

Related posts

http://www.shortinfosec.net/2008/05/information-security-and-strategy.html

I have received inquiries regarding my Datacenter Physical Security Blueprint . The questions were about the deadman door and how one works. So, here is a short definition, functional specifications and a blueprint of a dead-man door

A dead-man door is a high security access portal. For a movie representation of the deadman door, i refer you to Sneakers ("My name is Werner Brandes. My voice is my password. Verify me") The idea is to have two separate authentication processes, with the second one being performed while the authenticated person is 'trapped' inside a reinforced enclosure.

The second authentication is made against several biometric attributes of the person which are stored in a database, and always include weight measurement, thus preventing a second person 'piggybacking' with the first person.

I recommend a retina scan and weight measurement, since a fingerprint is very easy to fool - even seen on Mythbusters

Blueprint


Functional specification of a dead-man door
For the purpose of the specification, the doors of the dead-man door will be named:

• inside door - connecting the deadman door to the highly secure area


• outside door - connecting the deadman door to the rest of the facility

1. The deadman door should comfortably accommodate 1 person


2. The entire floor of the dead-man door should be connected to a scale sensors for weight measurement


3. The inside wall surfaces of the deadman door should be smooth and not have any ledges which may be used to trick the scale by supporting oneself on them


4. Both doors of the deadman door must open outward from the door enclosure.


5. Doors should be bulletproof, and at least 50% of the door surfaces should be bulletproof glass - preferably standard EN1522, class FB2 or higher (stopping a 9mm Luger fired at 5 m). Both doors should be equipped with door closer to close the door without human intervention


6. Both doors of the deadman door must be equipped with electronic locks controlled by a common controller. All electronic locks should have a mechanical lock override for emergency conditions. Both doors of the deadman door must be equipped with minimum two open-door sensors. (for redundancy)


7. When entering the dead-man door, each door should open under the following conditions - approved authentication (key card or key card + pin keypad) and other door lock is locked and there are no open door sensor alerts on the other door.


8. The person inside the dead-man door should have a selector to indicate in which direction he will go (which door to unlock)


9. When inside the deadman door, each door should open only under the following conditions - the other door is locked and there are no open door sensor alerts on the other door; approved biometric authentication and weight of authenticated person is within acceptable variation of database value - biometric authentication should always authenticate to the parameters of the person whose key card was used to enter the dead man door.


10. A mechanical override (unlock) of any door should always raise a silent alarm - regardless of conditions. All sensors and authentication mechanisms of the dead-man door should be connected to a central monitoring and alarm system, and each non-normal event should raise at least a silent alarm and lock the deadman door.

Panic conditions

A dead man door is a very powerful system access control system, but can be very dangerous if panic conditions are not taken into account.

1. Automatic controls - a predefined timer for passing through a dead-man door must be set-up. If within that time the second door does not open and close, an immediate alarm should be raised - this will deter attempts to tamper with the biometric authentication or locks as well as prevent an unconscious human to remain trapped in the door for a prolonged amount of time


2. Human sickness/panic - a large and visible panic button must be present inside the deadman door, to be activated upon human sickness/panic. Upon pressing this button, an alarm should be raised, an audible alarm with independent power source should be triggered and the electronic locks of the outside door must be unlocked.


3. Fire - the inside of the deadman door should have a fire sensor, and may have even a sprinkler system. Upon detecting a fire, the sprinkler system should be activated (if placed), an alarm should be raised and all locks of the both doors must be bypassed and unlocked.


4. Power outage - all door systems and authentication databases must have a UPS which will provide power surge and brownout protection, and will provide independent operation in short periods of power outage.

Related posts

Datacenter Physical Security Blueprint

The Cost of Datacenter Physical Security Blueprint

Talkback and comments are most welcome

Most companies have stringent security procedures. And in most companies, the security experts are usually exempt from these procedures in some way, under the pretext that this is needed in order for them to do their job as easy as possible. It must be understood that these experts are not superhuman or super honest, and restrictions also need to apply to them.

This post is triggered by a recent article in a Norwegian paper 'Security agent gets child porn sentence'.

Apparently, a National Security Authority agent managed to download 99 CD's of child pornography before he was discovered and arrested. This supports my point that security personnel are just ordinary people, and obviously some side on the criminal side. It is quite common to apply the "Do as I say, don't do as I do" philosophy.

On the other hand, these persons are given a very wide authority, responsibility and trust within a company, since it is their job to maintain security.

Regardless of given responsibility and authority, controls must be put in place for all employees. Any security expert trying to circumvent these controls has a hidden agenda, and red flags should raise immediately.

Here are 8 tips that should be observed for the company's security experts:

1. Security experts should use a standard user account on all systems (without administrator privileges)
2. Security experts should not be authorized to bring in and install foreign software except in special documented circumstances
3. Security experts should not have administrator password of any computer systems
4. Security experts' Internet access should be subject to the same rules as the rest of the organization. If exception is required due to business reasons, such exception should be provided via a guest access network for the laptop
5. If the security expert's laptop is subject to special treatment (granted administrator password, installation of foreign software etc.) should be treated as hostile in the corporate network, and be allowed only guest access to mail and Internet. Also, in such circumstances, no corporate specific software should be installed on the a laptop
6. Security experts should be subject to the same software security and audit policies that apply for other employees
7. Security experts should have very limited privileges to access corporate systems - access only to log review, with a read only privilege.
8. All documentation given for review to the security expert should be tracked, preferably in copy (send via digitally signed email, use corporate mail with archive tracking)

Related posts

DHCP Security - The most overlooked service on the network

Talkback and comments are most welcome

Regardless of the size and complexity of infrastructure you are running, it is always very important to have an established process of change management to your resources. If you fail to establish or enforce such process, errors will inevitably start to creep but will largely go on unnoticed, until something bad happens.

The example
A small company I visited yesterday is running several high profile paid content web portals. While discussing a research i did for them, the CTO changed the subject: I need a fast way to know when my staff made changes to my servers. I must admit that this question caught me by surprise, since I had no insight into their operations. After 15 minutes of conversation on the topic, i concluded that they don't have a process that controls which changes to the infrastructure are made when and under whose authority. This led to a situation where one developer implemented a new version of the software, while another made changes to access permissions. The result - a hacker made copies of their content and published it on IRC channels, resulting in direct monetary loss.

This is an excellent example that there is no company small enough to justify not having a strict change management process.

The rules

Here are the golden rules of establishing a change management process

1. Make a clear distinction between systems
   Production environment is the place where you run your business. Nothing except approved versions of approved software should be running there.
   Test environment is the place where you check your next versions. In configuration and set-up it should be as close to production as possible.
   Development environment is the place where you develop new products. It is to be expected to be riddled with all kinds of code, and some testing will be done on it, but don't confuse it with a test environment
2. Know exactly what is running in production - Establish a documented process of applying changes and versions to production. Make regular checks that this process is being used in daily operations
3. Develop changes based on current production environment - Unless implementing a entirely new solution, maintain a protocol by which all further development takes into account the setting and versions on production. This way, your next version will always start from a tested core code, where you know or have weeded out most of the bugs
4. Always run a full battery of test scenarios - When testing new versions, write test scenarios, and test the full software, not just the new features. It is very common for working functions to be broken by a seemingly unrelated change.
5. Never institute several changes simultaneously - If something goes wrong, no one will know what change is problematic, and everyone will blame everyone else. When making several changes make them one by one. Between each change, reserve as much time as possible to confirm that all is working before making the next change.
6. Always have a fallback plan when placing a new version in production environment - It is not WILL something go wrong, it is WHEN will something go wrong. The implementation team should have a written fallback plan when applying changes to production. This plan should include a responsibility for a human to oversee production operation at least in the first 12 hours after the change is made, to be able to react on first sign of trouble.
7. Assign responsibility to a person - Group responsibility doesn't work. Name one person Change Manager or Coordinator. It will be his responsibility to oversee testing results and changes on a daily basis and coordinate multiple changes.
8. Always insist on regular reporting - The CIO/CTO should receive regular monthly one page report on what changes were moved to production, test conclusions and next planned versions. Although not immediately useful to the manager, the responsibility for regular reporting will help to keep the process alive and used by the organization

Related posts

Security challenges in software development

Application security - too much function brings problems

Talkback and comments are most welcome