FBI pays $900,000 to hack into iPhone

This is what elite hackers get paid!!  It takes a few hours to do.

Hacked!

When people get hacked, they often asked me if I hacked their system (because I work as a profession hacker)? The answer is NO. I don't have time to hack stupid stuff.  I don't hack for free.  And I don't hack illegally. That's what losers do.

Most often the causes of people being hacked are:

1. they received an email that says they've won $10 million. "Please click here to receive." lol

2. they click on a popup that says their computer is hacked and to install the "anti-virus" software from the popup to clean. often the free "anti-virus" software is the trojan. even if it's not free, it's a scam for people to buy unnecessary software.

3. people are downloading software, music, and movies illegally. STOP IT. that's how people most often get hacked. they often use some kind of torrent software

4. people visiting risky websites and clicking on them.

5. opening an attachment from a friend that contains a funny joke

People should have 

a. a restrictive firewall up

b. anti-virus software running

c. update the software on their system to patched versions

d. and don't do any of the silly things listed in 1-5

Network Vulnerability Scanners

There are many network vulnerability scanners out there.  Many of them are poor quality.  For instance, one particular tool lists hundreds of vulnerabilities for a service running on the network simply based on the fact that version banner states it is a certain version.  These tools do not check for a vulnerability.

That's right.  Many of these tools do not check for a vulnerability.  Instead they look at version the number on an Apache web server or a MySQL server and then list hundreds of false positives.  The version number could be incorrect and/or patches may have been backported.  This is no different than static code analyzers that try to impress users with thousands of findings in fancy demonstrations that are false positives.

These tools are a waste of time and energy.  Get yourself a real tool that actually does a vulnerability check.

QualysGuard Private Cloud Platform Security Architecture and Pen Test Review

The QualysGuard Private Cloud Platform (QG PCP) makes many promises, one of which is that  vulnerability scan data can be hosted by a private cloud platform in a client's data center and under the client's control.  If taken at their word, this may seen promising, but the reality is that Qualys still will have to manage this platform remotely.  By doing so, they will have access to this data remotely and can pull it down to their site as needed.  Needless to say, Qualys requires the client to provide a backdoor to the system.

The Qualys PCP equipment is leased and never sold to the customer.  There are many legal issues with this which allows them to access their equipment.  They require the customer to give them remote access in order for them to manage it remotely.  That is a requirement and not an option.  They keep it a big secret how it is managed.

Remote Access

What kind of remote access to the QG PCP do they require?

1. Persistent iVPN tunnel
2. VPN remote access account

Qualys still has the means to pull the data back to Qualys through SSH/SCP even though it is hosted on a customer site.  In fact, Qualys does not allow the customer to monitor the network traffic being sent back to Qualys.  Such requests were flat out refused during a security assessment.  What they pull back is their business and the customer has no right to know.

Network Sniffer

Network monitoring had to be done outside of the QG PCP as Qualys did not allow internal network sniffing.  This traffic analysis did show a few weaknesses.

1. Emails were being sent to email server UNENCRYPTED.  Yes, one could see the message being sent as well as who the recipients were.  Emails were being back to Qualys through the Internet.  A lot of sensitive information were sent unencrypted including server names, configuration, scripts, running jobs, listening ports, full internal DNS names.


2. Internet connections from Indonesia were seen accessing the QG PCP even though it was supposed to be in a controlled access network in a data center

3. A lot of failed DNS requests to www.qualys.com and other qualys subdomains, looks like the system has not been fined tuned to be hosted at a client site.  The interesting thing is that it tries to do windows updates on its own by accessing the Internet.

4. Undocumented protocols used by the Qualys PCP; namely AppleTalk, CMIP-Man, and Feixin

5. syslog messages sent across the network unencrypted.  

Firewall Rule Analysis

Firewall rule analysis shows that SSH is allowed into the platform through VPN firewall as well as HTTP(S) protocols.

Internet Access

The Qualys PCP itself does access network traffic in and out of the controlled access network environment as seen in the diagram below.

1.    The Qualys PCP Service Network requires outbound communication for

a.    NTP – Time Synchronization

b.    DNS – Name Resolution

c.    SMTP – Email

d.    WHOIS – External Internet

e.    Daily Vulnerability Updates - External Internet.

WHOIS pulls information from the Internet and Daily Signature Updates are pulled from Qualys through the Internet on port 443.  In effect, the PCP is pulling information from Qualys through the Internet to retrieve updates.  A man-in-the-middle attack could intercept the update and instead return a malware update to the Qualys PCP provided that a vulnerability exists in the platform.  

2.    The physical scanners communicate to the Qualys PCP.  This requires that inbound port 443 be opened on the PCP.  Physical scanners in the DMZ also need to communicate to the PCP on port 443.  Access to the PCP from the DMZ increases the risk.

3.    Qualys SOC accesses the PCP through iVPN and VPN connections from the Internet for maintenance and support.

Virtual Scanners

A sniffer placed on a virtual scanner showed that it chose to use SSLv3, which is deprecated, by default on some servers to communicate to the Qualys PCP.  In particular, it uses SSLv3 with RC4-MD5.  MD5 is obsolete.  Qualys documentation claims they use TLSv1 and the latest modern secure protocols.

Application Analysis

Perl API

Application analysis was done by running Perl scripts against the qualysapi server and testing for vulnerabilities.  The server itself was found to be vulnerable by accepting login credentials for API requests via base64 encoding and passed through plaintext HTTP.  This could result of loss and capture of Qualys Admin credentials which could result in access to vulnerability scan results.

Web Application 
The Qualys Web Application tests resulted in a number of vulnerabilities.

Qualys PCP Internal

Additional vulnerabilities were found inside the Qualys PCP infrastructure itself.  It was found to be very insecure.  

Yahoo's Downfall

I predicted Yahoo's downfall in 2008 and told my coworkers about it.  The prediction had nothing to do with looking at financials.  It was being displeased with how crappy the Yahoo service is.  I pretty much was using yahoo for more than 4 years and got fed up with it and switched to Google.  A bad service isn't going to last.  Now the question really is if Marissa Mayer can save them?

Yahoo in Turmoil

Having a Safe Online Shopping Experience

Online shopping can be quite fun but it can also be quite dangerous as the Internet is full of scam websites posing as legitimate websites.  Some of these fraudulent websites are so well done that it looks legit.

Here are some pointers on having a safe online shopping experience:

1. Stick with well known and trustworthy companies when giving them your credit card and personal information.  Such companies are Google, Amazon, Microsoft, and a few others.

2. If there is a site that is not on the trusted list, do a google search for the name of site plus the words scam fraud reviews.  For example, google this: badwebsite.com scam fraud reviews.  Look and see if there are any/many bad reviews.  Some good reviews could be fraud as well, so use best judgement and common sense.

3. Make sure you have anti-virus with Internet protection from malicious websites turned on.  This does *not* guarantee 100% protection from malicious websites nor from virus infection but it certainly increases your chances.  Firewall is turned on.

4. Be careful of malicious and suspicious websites.  Don't think you are invulnerable and click on any site you want.  There is such a thing as drive by downloads that some anti-virus will not detect.  Yes, just by visiting a bad website, you could be infected and compromised even with all anti-virus, anti-malware turned to the max.  Be careful of what websites you visit.  If you google illegal software and music downloads, then most of the sites that turn up are bad websites.  If you google buying illegal drugs, there's a 99.9% chance you will run into a scam site.

5. Use McAfee Secure Search which filters out malicious sites or sites that have been hacked from your search results.  This is a McAfee Site Advisor plugin for your browser.  Google Safe Browsing is a similar service.  Having used both McAfee Secure Search and Google Safe Browsing, they seem to block out only a portion of malicious sites.  So many scam websites were still shown in the search results.  Unfortunately, it does not screen out all bad websites so you must still exercise caution.

6. Verify the reliablility and trustworthiness of the website by entering the web site address into:

1. McAfee Site Advisor. http://www.siteadvisor.com
2. scamadvisor.com
3. scamvoid.com
4. scamanalyze.com
5. ripoffreport.com
6. complaintsboard.com

Verify there are no bad ratings.

7. How long has the website been up?  If it's been up for less than 3 years and has no bad ratings, there could be a cause for concern.  Usually bad ratings take a few years to show up.  Most bad websites change their domain names every 6 months to avoid being blacklisted and having bad reviews written about them.  It's like how companies involved in fraud constantly change their names to avoid known detection. lol.

8. Look for a few good ratings on the website that sound legit.  This step requires some common sense. :)  Beware that there are a lot of fraud review sites set up by scam companies.  Make sure that the reviews you are reading are from a well known and respected community boards with a variety of opinions.  If some web site claims or reviews sound too good to be true, then it probably is.  Be careful in those situations.

9. When in doubt, don't buy.

10. Assuming nothing bad shows up so far, see if the site allows paying through a safe payment system such as Amazon Payments.  See if the website has that option.  If it does not, it may not be worth doing business with.  This way you are not sending your credit card information to them but you are sending PII (personal identifiable information) to them and that should be done with caution when sending such information to unknown random website on the Internet.  By the way, you are not likely to get your money back if you use Paypal and got scammed.

Best of luck to you.  While this is no guarantee you will have a safe and enjoyable online shopping experience, it certainly improves your chances by a dramatic factor.  If this sounds like too much work, then  just stick with point #1 and stay with well known trusted sites.

Things to Consider Before Accepting a New Job

While the promise of significantly higher pay may be enticing to some, here are a couple of things to consider before taking a job offer.  Most people just take a new job and hope for the best without a clear strategy.

1. What are their expectations?  Are their expectations significantly greater than that of your current employer?  Are you willing to do that?

2. What is the corporate culture?  Is it a sweat shop culture or laid back culture?

3. Will you be able to balance life and work at this new job?  For those who have a lifestyle outside of work.

4. How is the manager and his managerial style?  How does he/she treat people?  Some people grow up being treated with contempt and disrespect from their parents and have not learned how to behave in any other way and now treat the people they manage the same way.   They have not grown up emotionally and still operating like a poorly behaved child in a professional environment managing others.  Does this person seem to have a temper problem and yell at people a lot?  Are they a slave driver with whip in hand?  Do you think you will be able to communicate issues to this manager?  Does this manager able to get things done?  Does the manager's personality mesh with yours?  It's good to talk to the boss face to face to get a gut instinct if this is a person you can trust or does he/she look like they lie a lot to promote themselves?  Does he/she seem sleazy and shifty-eyed?  Does this person seem ethical or underhanded?  Will they throw you under the bus when the going gets tough?  

5. Do the coworkers look like people you would want to spend time working with

6. Will you have to relocate?  Do you like the new city?  Does the new city have a lifestyle you could enjoy?  How will this affect your personal life?

7. Is it a company you can trust?  Does it have questionable HR practices that may affect you personally?
  
8. What is the turnover rate for the team?  Do they have a hair trigger for firing people?  How likely are you able to keep this job and still be happy?

9. Outside of money, does this job meet your career aspirations?  Will this take you where you want to go?  Will it advance your career or is it a dead end job?

10. Will you enjoy the job?  Do you think you can be happy with this job?

11. Are you taking this job, which you may not like, only for more money?  Consider adjusting your lifestyle so that your expenses are lowered.

12. Is this company's future stable?  Is it a startup?  Are you able to financially handle the risk that this startup may go out of business or be laid off if their profit expectations are not met?  Small companies sometimes go through a massive hiring frenzy followed shortly thereafter by a massive firing fiesta.  Long term contracts at large companies (Fortune 20) are often more stable than full time positions at small companies (not Fortune 1000).

Problems with Google Voice

It's amazing to see people write great reviews of products they never use.  One such product/service is Google Voice.  The concept of it seems like a good idea.  Keep your personal number private and give out only your public number, google voice number, which can change as you see fit.


Unfortunately, there are some problems with their implementation.

1. Google Voice cannot send nor receive picture nor multimedia SMS text messages, at least not on an iPhone.  This really sucks and people are not told upfront about this by Google but after using for a little bit who sees the message, "did you get my picture?" and realize pictures cannot be sent nor received through this service.  Digging through their support pages you will eventually find this.  Had I known this ahead of time, I may not have switched to Google Voice.  This takes out half the fun of sending SMS messages.

2. Text message are often lost.  I never had a single lost SMS message until I switched to Google Voice.  It seems a number of reliable people have told me sent me text messages which I never received.  And it never shows up on www.google.com/voice history either.  For those who send 1 text a week, it may not be obvious but I send/receive 400 texts a week easy.  Having heard complaints enough about missed texts on a consistent basis, I realized Google Voice is not a reliable service.  If you are looking for reliability, look elsewhere.

3. International text messaging does not work.  When I was using a regular cellphone, I was able to send International SMS text messages without problems.  Not with Google Voice.  The message you get when trying to send is "destination not supported".

4. Google Voice transcription is not exactly accurate but it is certainly helpful from having to listen to unnecessary voicemails.

Security Architecture and Leadership Review

Let's look at a few practical and examples of a Security Architecture and Leadership Review.

Lack of Proper Security Controls and  Effective Anti-Virus Solution
During a penetration test, netcat and a eichar test files were successfully uploaded to a SharePoint server as a test virus files because it is known that SEP (Symantec EndPoint Protection) would detect it.  For those in the security know how, netcat is not a virus and does not even meet  the loosest definition of a virus.  Symantec Anti-Virus, which was installed on the server, not only did not remove the file but instead kept the file on the server allowing further user downloads.  Their Security Team erroneously believed the file was an actual network virus that was spreading all across the network.  Let's take a closer look.

First, Symantec did detect it and claimed it removed the file every few minutes sending out alerts constantly. 

Symantec detected netcat as a generic 'Trojan horse/malware' and sent out an alert "Critical Network Virus Detected".  It falsely labeled netcat as a "critical network virus" without even being able to identify the alleged virus by name.  Anyone who has done half-decent virus research knows that  even a half-decent anti-virus product would identify the name of the virus that it found.  The interesting thing was that Symantec identified netcat as a network virus.  It is clearly evident that Symantec doesn't know what a virus is.  A virus is a self-propagating file.  Netcat is not such a file.  The Security Team actually believed a real network virus was uploaded without checking any facts but relying solely on Symantec email alerts told them.  Blind believers in a product.

People think that because Symantec is a popular AV product, that makes it a good solution.  Well not exactly.  That's like saying because McDonald's is one of the most successful restaurants chains ever, that what they serve must be good food.  

Clearly the security controls implemented were not even effective in handling known test files.

No Capable Forensic Investigations
The Security Team and Security Operations Center (SOC) have no need of how to properly conduct a forensic investigation.  They had no EnCase Certified (Forensic) Examiner on staff.  Instead this duty is given to the SOC (Security Operations Center),

The SOC had no experience in forensic analysis and methodology investigated and claimed that it was a real virus and not netcat, though they could not identify which alleged real virus it was and how it was a virus in the first place, or what this alleged virus did.  Their only proof was that because Symantec says so.  Real forensic skills here! lol

The SOC were challenged as to their analysis and findings.  The SOC "re-investigated"and the findings were personally verified by the Security Manager and he concurred.   Their final statement was, "That forensics don't lie."  Yes, but bad analysis does.  Lack of basic skills and detailed analysis in forensics investigations do lie.  Their bottom line, "If Symantec says so, it must be true."  This is like, "If FOX News says so, it must be true!"  lol. They have an over-reliance and belief in tools and easy answers because they lack the work ethic to do the hard work themselves. It is obvious that security management does not know how forensic investigations are conducted, understand the rudiments, nor do they have an idea of how to hire the right people as is evidenced by the results.

If the SOC investigator or Security Manager had taken time to read the actual email by SEP or the logs, they would have found out the file only existed in the Recycle Bin.  Why?  Because when the file is accessed by the SharePoint user, SharePoint pulls the file from the internal SQL Server database and makes a temporary copy on the file server in the temporary area.  This is when SEP detects it and moves it to the recycle bin and sends out an alert.  So if they actually knew how to do an investigation, they would have found out that anytime anyone attempts to download the file from SharePoint, SEP would move the file to the Recycle Bin and trigger a SEP alert.  Because SEP cannot delete a file from SQL Server, this is what happens.  A possible recommendation was that they buy a SEP SharePoint license which would resolve this problem but this was pretty much ignored because they said they had all the security controls in place.  There is no self replicating mechanism from netcat in order to be called a virus.

As you can see, the SOC and Security Teams do not have the knowledge of how technology works, in this case specifically how SEP works with SharePoint.  And if they had read the logs or the email body, instead of just the email subject line, or know how to do a forensic investigation, they would have found this out.  Even when given a second chance, they product the same results. 

What if a critical investigation had to be conducted?  They are dealing with hundreds of millions of records of personal consumer account balances, individualized transactions, social security numbers, and credit card data and have no qualified forensic examiner on staff.  Should they not have a qualified forensic examiner on staff?  How many data breach investigations have they conducted improperly?

Poor Decision Making
Clearly in the above, it is evident that Security Management makes poor decision as whose results to trust.  This is poor judgment.  They constantly make poor decision because they lack the technical ability and work ethic to do their job right.  Even when told what the real issue was, they continued on their misguided path out of some obstinate big ego high school mentality.  It cost the company a fortune financially and they forced the various teams to undergo unnecessary and often time consuming processes that make it very difficult for them to do their primary job functions.  The poor judgments made affect the company's bottom line. 

Mediocre Penetration Testing
During penetration tests, numerous high level vulnerabilities were found that existed for at least half a decade that their entire system of security architects and penetration testers never found.

Too Many High and Critical Issues Not Fixed
There are literally thousands upon thousands of identified vulnerabilities here, many of which are rated as high and critical vulnerabilities that never get fixed.  In fact, they claim they don't have time to fix them so they are never addressed for fixing.

Poor Relationships with Various Teams
The Security Team has poor relationships with other teams especially IT Operations where they make recommendations that could not even be implemented.  It is a hostile type of relationship with heavy politics.  If the security team had knowledge and experience of how technology actually works, they would have realized their recommendations could not be implemented.  The teams would get along better once they stop making recommendations that do not make sense.  This makes the jobs of the various teams much more difficult and costly.

The Security Team's whole strategy was to win at all costs and make themselves look good.  There was never a strategy of developing a working relationship and working through problems with other teams.  They didn't care.  They really never did.  It was all about them, 100% self-absorbed.  The only time they get motivated to do anything is when the other teams are getting ready to hang them with a noose.  Then they are motivated, for a short time.

Poor Secure Code Analysis
The Security Team relies fully on automated tools to find coding problems.  Unfortunately, the tool they use is not very good, has high false positives, and false negatives as well.  They make software development fix a lot of unnecessary bugs all the while ignoring real analysis of critical security issues.  This is done mainly due to their lack of skill in manual code analysis.

It seems the Security Team's strategy was to do the minimum work necessary on their part to get by.  There was never any passion or spirit on doing the right thing. 

No Effective DLP Solution
PCI and banking account information were sent in the clear on their networks.  This was never detected by their DLP (Data Loss Prevention) system.  This was only discovered because the customer reported doing so.

Conclusion
In conclusion, the Security Team needs much work,  they need to work on being detailed oriented, develop the discipline to do forensic analysis, get a qualified forensic examiner, learning to do the right thing instead of just trying to look good, have more interest and passion in their work, overcome their reliance on tools and easy answers, have a strong work ethic, need good decision making strategies, provide value and develop working relationships with various teams.

Implementing PCI DSS 2.0 for Secure Development Lifecycle (SDL)

Pen Testing Process, Remediation, and Secure Development Lifecycle

Starting a pen testing process for PCI Compliance can be quite a challenge for many organizations.  Often this process is cumbersome because it rarely has buy in from Application, Infrastructure, and Operations Teams.  In fact, these teams often feel they are forced into it and are reluctant to comply because it is not their problem.  They feel security is the problem of Compliance and not a concern of the product or system itself.  They often do not want to foot the bill for implementing security measures and testing the product. 

We need to move away from this model, the model that security is not the responsibility of the application owners.  This model is not conducive to teamwork and growth in the organization as a whole.  It often feels that Compliance is fighting a one army battle against legions of other armies.  And while Compliance often wins, it is often overwhelming to work in an environment of such politics.  It is hard to get 100% PCI Compliance with this model because it relies on the goodwill of the teams to do what they feel is right.  There is often a lot of politics to get them to even cooperate.  Obviously, this model leads to much distress and headaches in implementing PCI within an organization because people don’t understand what their roles are.  There is always a certain percentage that fail to cooperate and they have to be strong armed.

The model we need to move to is ownership of security and PCI Compliance from within the application teams and network operations.  They have to take responsibility for the security in their product and systems.  They have to be proactive in maintaining PCI Compliance.  This is the model often used in companies that have successfully implemented PCI Compliance with a finely tuned model and everyone knows their role.  There is no need to coerce application teams and explain to them why they need a security test done hoping they will cooperate.  We need to move into a model of taking responsibility and taking ownership of security and PCI Compliance.

The new model stresses maturity in the pen testing process, remediation, and secure development lifecycle where the responsibility of getting the pen test conducted rests upon the application and system teams and Compliance is there to arbitrate if any issues arise.  Compliance is there to enforce and report on PCI Compliance as well but the responsibility does not rest entirely upon them. 

This is a proposed top down model.

In this new model, the application teams should understand the Secure Development Lifecycle (SDL).  This model starts off with understanding the 4 business areas of secure software development:

1.     Governance

2.     Software Development

3.     Testing

4.     Deployment

The security practices are implemented as follows for these 4 business functions:

I.                 Governance

                                                    i.     Strategy and Metrics

                                                  ii.     Policy and Compliance

                                                 iii.     Education and Guidance

II.               Software Development

                                                    i.     Risk Assessment

                                                  ii.     Security Requirements

                                                 iii.     Secure Architecture

III.              Quality Assurance

                                                    i.     Secure Design Review

                                                  ii.     Security Testing

                                                 iii.     Secure Code Review

IV.             Deployment

                                                    i.     Vulnerability Management

                                                  ii.     Environment Hardening

                                                 iii.     Operational Enablement

Governance

Governance consists of the processes and procedures related to how an organization manages overall software development activities.  This includes providing education and guidance to application and platform teams on security topics relevant to individual job functions.  This is so that everyone understands their job roles and learns to work with Compliance instead of against them.  Policy and Compliance involves setting up a security and compliance control and audit framework for the organization to achieve increased assurance in software under construction and in operation.  Strategy and Metrics involves the overall strategic direction of the software assurance program and instrumentation of processes and procedures to collect metrics about the company's security posture.

Software Development

Software Development consists of processes and procedures of how the organization defines goals and creates software within development projects.  This includes product management, requirements gathering, high-level architecture specification, detailed design, and implementation.  Here a risk assessment is performed on the application by a Security Architect or through Compliance, security requirements are defined, and a secure architecture is defined by the application security architect.

Pen Testing

As the responsibility of the application team to get a PCI application pen tested annually, or after a major change, is understood and owned by the application team, it is their responsibility to schedule the penetration testing and make sure the vulnerability findings are remediated.  It is their responsibility to meet with PCI Compliance. 

Penetration tests are not just limited to applications but also include host, network, physical, and work flow/policy processes.  

The findings of the penetration test are uploaded into a Governance Risk Compliance (GRC) system and the remediation process is tracked there.  Reports can be executed at any point to determine the PCI Compliance posture of the organization.  The status of each vulnerability is tracked by date of finding, status such as fixed or overdue, amount of time elapsed since finding was discovered, and more importantly the product or application owner.  This allows management to see at a snapshot how individual departments and teams across the enterprise are in relation to compliance.  It also promotes accountability.

Secure Development Lifecycle

Security is not something that is done at the last minute before releasing a product to production.  Security is something that has to be built into the product.  Security has to be incorporated into the product development lifecycle.  Software development can be roughly broken into 5 phases:

1.     Analysis

2.     Design

3.     Implementation

4.     Testing

5.     Deployment

Analysis Phase

At the analysis phase where application requirements are being defined, the security requirements must be taken into account.  This is where the corporate security standards and regulatory requirements are taken into account when developing an application and put into the application requirements.  A security risk assessment is performed on the application by a Security Architect or through Compliance

Design Phase

At the design phase, the application security architect reviews the application architecture and defines a security architecture.  Threat modeling can be done here but is not required for PCI.  The application security architect also designs and makes recommendations on needed security design based on the application design and looks for any security oversights by the application team.  This is called a secure design review and ensures adequate security mechanisms are in place and adherence to corporate and regulatory security standards are designed into the application.

Implementation Phase

The implementation or coding phase requires that the application developers code according to the security standard of the organization.   They may or may not entail help from the application security architect to assist on how to handle the more difficult implementation parts.  Secure code review should be done by software development at this point as code is being developed.  Assistance from automated static code analyzers can be used to help the developers.

Testing Phase

The testing phase will consist of Quality Assurance (QA) conducting security testing.  QA will run the final secure code scan and verify that all important  security defects have been resolved by the development team prior to release.  Compliance can assist with the secure code review and assigning business priority.  Penetration testing can be done on the application prior to release but is not required by PCI unless it is a major application upgrade.  All identified issues are to have a remediation plan and schedule.  Critical vulnerabilities must be fixed prior to releasing software in production.

Deployment Phase

The deployment phase consists of the processes and procedures of how an organization manages release of software developed.  This includes deploying applications to internal or external hosts, and the normal operations of software in the run-time environment.  This includes vulnerability management, environment hardening, and operational enablement.   The security architect does a final review of the application and network deployment configuration prior to release making sure that it is deployed in a secure manner and meets with the company’s security standards.  Application security monitoring and an incident response plan is needed.

Pen Testing Process

The following process explains how to implement Pen Testing to meet PCI Compliance.

I.                 Identify Type of Pen Tests To Be Conducted

a.     Work Flow/Policy

b.     Physical

c.      Network

                                                    i.     Internal devices

                                                  ii.     Perimeter devices

d.     Host

                                                    i.     Services

                                                  ii.     Applications

e.     Application

II.               Education

a.   Educate teams as to their responsibility for maintaining PCI Compliance

III.             Identify PCI Scope

a.     Identify applications and pen tests to conduct

b.     Notify application and system owners of the compliance they must maintain

IV.            Identify Rules of Engagement

a.     What can and can not be done.

b.     Produce pen testing authorization letter

V.              Logistics

a.     Application and system owners schedule required pen tests

b.     Sign Off on pen testing authorization letter

c.      Coordinating the pen test 

d.     Give access to the environment for testing including test accounts and support

VI.            Actual Pen Test

1.     Information Gathering

2.     Reconnaissance

3.     Enumeration

4.     Vulnerability Scanning

5.     Exploitation

6.     Documentation

VII.          Remediation

a.     Distribute pen test report to application and system owners

b.     Log all defects from pen test into a bug tracking system

c.      Meet with application or system owners to discuss test and timetables for remediation

d.     A GRC system and/or project manager needs to track the vulnerabilities over time and push the application or system owners to fix all issues.