Are security audits, vulnerability assessments and penetration tests same?

The answer is no. All three are different but interlinked.

Security audits:

Auditing is related to guideline/ check list that the solution should be followed all these guidelines. For example, for payment applications should follow PCI guidelines.

Penetration tests:

Penetration testing is nothing but a specialized & non functional testing where the testing will be done to make sure how secure the application is to internal and external threat through flaws in the design, development, deployment, up gradation and in maintenance of the application.
In short, penetration tester is a paid hacker (you can say ethical) where he tries to emulate the hackers view on the application before deployment of the application so that unthinkable can be avoided in production environment.

Vulnerability assessments:

At high level or in broader picture Assessment involved in compliance, audits, testing.
If we split one bit then we can divide this assessment in two steps.
1. Pre development of the solution.
Will try to figure out the guidelines/ compliance, standards, tests that the solution should follow.
2. Post development of the solution.
Once application is developed it will go through the assessments like compliance audits, penetration testing and root cause analysis for each vulnerability came out during testing.
In short assessment is not a one step effort or one phase approach. It includes from beginning to end while developing the solution.

5 Testing schools

Most of the testers are testing the applications, products, devices etc without knowing they are following/ practicing/ belong to one among the 5 testing schools. Like me, started testing without knowing I belong to context driven testing school.

Based on my past experience in security testing, I strongly believe that every security tester/ vendor/ process should follow/ incorporate the context driven testing school model. This is time saving, cost saving, progressive, aggressive and more towards finding the bugs rather than documentation and process.

1. Analytic School

This school practices testing as rigorous
and technical with many
proponents in academia

2. Standard School

This is a way to
measure progress with
emphasis on cost and
repeatable standards

3. Quality School

This school emphasizes process,
policing developers and
acting as the
gatekeeper

4. Context-Driven School

A school emphasizes people,
seeking bugs that
stakeholders care about


5. Agile School

A school uses testing to prove
that development is
complete; emphasizes
automated testing

Conducting an interview is an art

In one of my corporate training, it was surprising to know that conducting interview is not a ordinary thing. In this there are different approaches, planning & techniques are involved.

Experts say best way is to follow “Funnel model/ technique”. This says,
1. Question should always be open. Open means, it should lead for the discussion or scrutinization.
2. Once you open question for discussion, scrutinize properly.
3. Once you scrutinize then close it.

It is said that, for good interview it requires minimum around 45 min.

Security in Cloud computing: Risk Prevention In VMM

VMM Should support following properties:

Isolation :Software running in a virtual machine cannot access or modify the software running in the VMM or in a separate VM.
Inspection: The VMM has access to all the state of a virtual machine: CPU state (e.g. registers), all memory, and all I/O device state such as the contents of storage devices and register state of I/O controllers. So that VMM can monitor VM.
Interposition: Fundamentally, VMMs need to interpose on certain virtual machine operations (e.g. executing privileged instructions). For ex. if the code running in the VM attempts to modify a given register.

Security in cloud computing: Vulnerability in Virtualization

Some vulnerabilities have been found in all virtualization software, which can be exploited by malicious, local users to bypass certain security restrictions or gain escalated privileges. For ex.

The vulnerability in Microsoft Virtual PC and Microsoft Virtual Server could allow a guest operating system user to run code on the host or another guest operating system.(Vulnerability in Virtual PC and Virtual Server Could Allow Elevation of Privilege )
A vulnerability was found in VMware's shared folders mechanism that grants users of a Guest system read and write access to any portion of the Host's file system including the system folder and other security-sensitive files.
A vulnerability in Xen is caused due to an input validation error in tools/pygrub/src/GrubConf.py. This can be exploited by "root" users of a guest domain to execute arbitrary commands in domain 0 via specially crafted entries in grub.conf when the guest system is booted.

Security in cloud computing: Security Issues from Virtualization

Type of virtualization provider is using- ParaVirtualization or full system virtualization.

Instance Isolation: ensuring that Different instances running on the same physical machine are isolated from each other.
Control of Administrator on Host O/s and Guest o/s.
Current VMMs do not offer perfect isolation: Many bugs have been found in all popular VMMs that allow to escape from VM!

Virtual machine monitor should be ‘root secure’, meaning that no level of privilege within the virtualized guest environment permits interference with the host system.

Tool vs. Manual approach

Using a tool for security testing is good approach and helps in quicker assessment of the application. Saying this, tool based approach should not be the only approach because after all tool is a tool and there will always be a human factor that can’t be neglected. Tool runs on specific set of rule sets, there will be fair bit of chances getting “False true” vulnerabilities. Also in our own experience we have seen that few of the vulnerabilities were did not detect by tools and even though same set of rule set used but reports were inconsistent for different applications. Even after using the tool for greater extent, it would be better at least revalidate manually before sharing with the stake holders. There should be a proper blend of manual and automated approach to discover security vulnerabilities in web applications. Automated tools were never intended to, and should never entirely replace, the manual penetration test. However, if used correctly, automated tools can be used by organizations to find a broad range of technical security vulnerabilities in web applications, saving time and money, with manual penetration testing being used to augment the results for logical vulnerabilities.

Refer:Security acts May 2010 Issue 3

Cloud computing: Security a major Concern

1. Security concerns arising because both customer data and program are residing in Provider Premises.
2. Security is always a major concern in Open System Architectures

One of the best ways to do Security/ Penetration testing.

As Security/ Penetration testing is non functional requirement so this is entirely a different ball game and my experience says the same good old strategy or approach of SIT doesn’t work in this case. So security/ pen tester should follow entirely new kind strategy or approach.

In my experience security testing should follow “context driven testing school” model of execution.

http://www.context-driven-testing.com/

IBM appscan a black box security assessment tool

I started my security testing career with manual security testing and IBM appscan tool.
IBM appscan has two variants, one is standard edition and another one is enterprise edition. If I am not wrong, IBM says, appscan enterprise engine name as “BOBY”.

The purpose of two variants because the intended to server different types of requirements.

In my experience,

Standard edition:
1. Covers issues like privilege escalations.

Enterprise edition:
1. Can manage the assessments at organization level by concurrent scans.

Best way to do the database security testing

As I never learnt theoritical what is security testing, I learnt security testing while practically testing/ assessing the applications. Based on my experience,

1. Take only read only access for DB assessments.
2. Don’t touch data items of database.
3. Do assessments only at configuration level.
4. Use automated tools.
5. Better not go for manual assessments because of various practical cascading issues.

Database security testing

Normally when we talk about application security I have seen many vendors they end up in doing in front end assessment. The front end may cover from GUI to app/ web servers.
The big question is, is it enough? It is agreed that the hacker uses the front end of the application to hack the application but one of his goal would be to reach the data and data lies in database. So, there is no point in securing the application only from front end.
We need to make sure that the application should also be secured from back end as well.

Code review in application security testing

Should I scan client side code?

In short: prioritize it with lowest priority.
When considering scans of client side code, two cases are to be considered:
Vectors restricted to the clientWith such vectors, no information or control travels between the client and server therefore attacks can exploit only information located on the client side. Since web-applications are expected not to store sensitive information on the client, no sensitive information is compromised.
To illustrate this point, consider the SAN-25 list of top 25 most critical risks, published by CWE. 23 of the risks in the list are purely server side with the other 2 being mostly server side. This means that more than 24 out of the top 25 (96%) most critical risks do not consider the client code.
Bottom line – client side code is of very little significance
Vectors originating from the client and passing on to the serverOnce inputs cross the boundary to the server, sensitive information is accessible, give rise to the requirement for substantial security measures. However, all security standards consider inputs received at the server side to be tainted. Regardless of client side sanitizations. Regardless of secure network channels (e.g. SSL). As a result, security directives require ignoring input manipulation, validation and sanitization performed on the client side. The client side code is (once again) out of the picture.
A supporting reference can be found in OWASP’s answer to the question “I'm using client side JavaScript code for checking user input. Isn't that enough?”
Bottom line – client side is of no significance

I found one interesting tool from Checkmarx. Following is the overview of the tool. 

CxEnterprise Technology
Why scan source code?

In short: Because it is simpler, faster, cheaper and more accurate.
More accurateCompiled binaries are optimized for many things: CPU utilizations, memory consumption, multi-processing. One thing compiled binaries are not optimized for is static code analysis. In fact, most optimizations impair the accuracy of such analysis. CxEnterprise utilizes Checkmarx’ innovative Virtual Compiler which is optimized to a single end – providing the utmost accurate static analysis results.
SimplerWith CxEnterprise you need not retrieve every insignificant external library and build the entire project beforehand. You can scan your project by simply right clicking it in the IDE or have it scanned directly from the source code repository on a daily/weekly basis.
FasterWith no retrieval of external modules and no pre-compilation there is almost no setup time prior to the scan. Having the Virtual Compiler assuring utmost accurate results means there is no false-positives sieving time after the scan, as well. As a result, fewer people spend less time on auditing more lines of code.
CheaperSince sources need not compile properly, you can start scanning as soon as you start coding – before code changes are even considered fixes. No need for re-coding and consequent re-testing. No more deadline delays. And subsequently – your projects will cost less.

Can I scan a project that interfaces a module the sources of which I don’t have?
If short: Sure you can.
Out of the boxSince CxEnterprise utilizes its own Virtual Compiler, the code is not required to fully link. Objects declared in the “missing” module are regarded as black boxes. Therefore, data passed to an object declared in this module is considered to be influencing any data retrieved from the same object.
Customize to trace functionalitiesIt might be that you can map the functionalities certain methods in the “missing” modules serve. Functionalities such as: submitting queries to a database, retrieving input from users, converting object to numerical values, sanitizing inputs and more. In such cases you can customize CxEnterprise to consider these methods for their functionalities.
Example• Facts:Project X uses the method submit(String query) for submitting queries to a database.
The source files in which submit is declared are not included in scanned sources.
• Out of the box:Scans will complete successfully. submit will be considered as a neutral method.
• Customization:Customize CxEnterprise to consider submit as database access (takes less than a minute).
• Outcome:Any invocation of submit that receives a query influenced by un-sanitized input will be alerted on as potential SQL Injection.

Levels of Security violations

Violation type# 1: Curiosity

A curious person who wants to just know some of the details about you like phone number or your salary, and He may be internal or external. I am sure you guys won’t want this to happen with you. So, curiosity is one of the possible violations.

Violation type# 2: Ethical Hacking

Second possibility is, a person telling himself an ethical person wants to thumbs you down by executing some tricks on the production environment. Even though he is not interested in you or in your money and will help you to fix the vulnerability but he is still dangerous to you because he is executing his tricks on your production environment. So, ethical hacking is another possible violation.

Violation type# 3: Serious Hacking

The third possibility is about serious hacking, where their main intention is to break your application, steal our money, and do all types of illegal activities.

The threat never stops here,

Violation type# 4: By user/ By some typo error

The fourth level of security violation may come none other than from yourself and you yourselves may become a potential threat to your application. How means, you may be the cause due to typo error like “$” insert which in turn may be compiled as a shell command.

Security Testing growth

I forgot the source but I came to know while doing some market research that the growth figure of security testing. Today it has grown to $1.8 Billion and since last 2 years it has 40% Growth.

By looking at above figures it is clear that security testing is growing pretty fast and business people are understanding the consequences of security breach.

List# 3: Few of the vulnerabilities that I encountered

List# 2: Few of the vulnerabilities that I encountered

Please click on the image to enlarge

List# 1: Few of the vulnerabilities that I encountered

Please click on the following image to enlarge



The remaining list will be posted in subsequent posts.

Facts to Myths of Application Security

Myth 1: We have firewalls in place.

The fact is.-
Access to the server through ports 80 and 443 makes the web server part open to external perimeter defenses.
- Vulnerabilities in the web server software or web applications may allow access to internal network resources.

Myth 2: We encrypt our data.
The fact is.

Not sure which encryption methodology will protect the data.
Let us say if the hacker comes to know abt the encryption techiniques used by the developers, there are several tools in market where we can decrypt the encrypted data.

Myth 3: We have a privacy policy.
The fact is.

No full proof policy till date. This is only theoretical which is difficult to incorporate programmatically in real time.

Myth 4: The IDS (Intrusion Detection System) protects my web server and database.
The fact is.

- The IDS is configured only to detect signatures of various well-known attacks
- Attack signatures do not include those for attacks against custom applications. An IDS (for example Snort) uses deep packet inspection to view the payload of packets into the network. By using signatures (blacklists) malicious payloads can be stopped before entering the network.

Myth 5: SSL secures my site.
The fact.
- SSL secures the transport of data between the web server and the user’s browser
- SSL does not protect attacks against the server and applications
- SSL is the hackers best friend due to the false sense of security

Myth 6: My application is internal
The fact.
- Threats are not only to external applications, threats are applicable to internal applications as well. Various published reports have been proven that security risk to the application will be more internally than externally. However , taken the example, which is our internal application any employee will be more aware of this application than external user and it is not difficult for any internal user to hack this and see anyone’s internal data

Insider driven fraud costs US enterprises over $600 billion annually.