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.

Comparison of Android and iOS Security Architectures

Similarities

1.     Data Encryption

2.     Memory Protection

a.      ASLR has been implemented as of iOS 6 and Android 4.1 JellyBean.

b.     DEP, Stack and Heap protection, XN.

3.     Sandboxing

a.      File permissions

b.     Application processes run in separate non-privileged user mode

4.     Secure KeyChain

a.      Android 4.0

Differences

Android

1.     Independent App Code Signing

a.      There is a need to have a independent third party sign applications such as VeriSign.

2.     Open Boot Architecture

3.     Applications request permissions to access:

a.      Address Book

b.     Network

c.      Send SMS messages

iOS

1.     Apple App Code Signing

a.      Apple personally vets and signs third party apps

2.     Secure Boot Chain

3.     Applications do not need permissions to access:

a.      Address Book

b.     Network

c.      Send SMS messages