21. Secure Application Development
- The Secure Application development policy is a plan of action to guide developers decisions and actions during the software development lifecycle (SDLC) to ensure software security.
- This policy aims to be language and platform independent so that it is applicable across all software development projects.
- The adherence to and use of Secure Application Development Coding Policy is a requirement for all software development on Mighty Group information technology systems and trusted contractor sites processing Mighty Group data.
Each phase of the SDLC is mapped with security activities, as explained below:
- Design Phase.
- Identify Design Requirements from security perspective.
- Architecture & Design Reviews.
- Threat Modelling.
- Coding Phase.
- Coding Best Practices.
- Perform Static Analysis.
- Testing Phase.
- Vulnerability Assessment.
- Fuzzing.
- Deployment Phase.
- Server Configuration Review.
- Network Configuration Review.
Development of code shall be checked and validated with the most current versions of Mighty Group Coding Standards for Secure Application Development. All code developers shall verify that their code is in compliance with the most recent and approved coding standards and guidelines
Only validated code shall be implemented into Mighty Group production environment.
A review and validation ensures that code exhibits fundamental security properties to include correctness, predictability, and attack tolerance
Application Code Developers shall:
- Ensure code meets the level of confidence that software is free from exploitable code vulnerabilities, regardless of whether they are already designed into the software or inserted later in its life cycle.
- Ensure code provides predictable execution or justifiable confidence and that the software, when executed, will provide security functionality as intended.
- Coding techniques must address injection flaws particularly SQL injection, buffer overflow vulnerabilities, cross site scripting vulnerabilities, improper access control (insecure direct object reference, failure to restrict URL access, directory traversal etc.,), cross site request forgery (CSRF), broken authentication and session management.
- Never trust incoming data to the system, apply checks to this data.
- Never rely on the client to store sensitive data no matter how trivial.
- Disable Error messages that return any information to the user.
- Use object inheritance, encapsulation, and polymorphism wherever possible.
- Use environment variables prudently and always check boundaries and buffers.
- Applications must validate input to ensure it is well-formed and meaningful.
22. Penetration Testing Methodology
In this section should be listed the risks inherent in conducting penetration testing over the information systems of the Mighty Group. Additionally, it should be noted for each mitigation measures that will be taken. Examples might be:
Example 1#
Risk: Denial of Service in systems or network devices because of the network scans.
- Mitigation measure 1: Network scans must be performed in a controlled manner. The start and end of the scan must be notified to responsible personnel to allow monitoring during testing. For any sign of trouble will abort the scan in progress
- Mitigation measure 2: Scanning tools must be configured to guarantee that the volume of sent packets or sessions established per minute does not cause a problem for network elements. In this sense, we must perform the first scans in a very controlled way and a use minimum configuration that may be expanded when is evident that the configuration is not dangerous for network devices or servers in the organisation
Key staff involved in the project by the organisation will be listed:
- Technical Project Manager.
- Chief Information Security Officer (CISO).
- Chief Information Officer.
- Head of Communications.
- Responsible for web site www.mightygroup.global
- External intrusion tests will be performed remotely from the supplier's premises.
- Internal intrusion tests will be conducted in the office Mighty Group of the Organisation.
- Audit team must to have access to the Organisation's network. It must manage access permissions to the building early enough to ensure that the audit team can access without problems during planning period.
- All the tests will be conducted from the equipment owned by the audit team so no equipment for the execution of the tests is required. The only requirement in this regard will be to have an active network connection for each member of the audit team. Those connections must provide access to the target network segment in every case.
- If an incident occurs during the execution of the tests that have an impact on the systems or services of the organisation, the incident should be brought immediately to the attention of those responsible for incident management in the project.
It should be noted that in order to comply with PCIDSS the scope of the test should include, at least the following:
- All systems and applications that are part of the perimeter of the data environment card (CDE)Example:
- Systems included in the scope: System 1: IP: System: System Description System, 2: IP: System: System Description Wi-Fi network the Mighty Group.
- Applications included in the scope: Application 1: URL: Description of the application.
- Systems excluded from the scope: System 5: IP: System: System Description, System 6: IP: System: System Description.
- Applications excluded from the scope: Application 3: URL: Description of the application.
- Technical tests must follow the Open Source Security Testing Methodology Manual (OSSTMM).
Tests must be conducted at network, system and application level and must ensure that at least identifies any vulnerabilities documented by OWASP and SANS, as well as those identified in the PCIDSS standard v3:
- Injections: Code, SQL, OS commands, LDAP, XPath, etc.
- Buffer overflows.
- Insecure storage of cryptographic keys.
- Insecure Communications.
- Improper error handling.
- Cross-site scripting (XSS).
- Control of inappropriate access.
- Cross-site request forgery (CSRF).
- Broken authentication and incorrectly session management.
- Any other vulnerability considered High Risk by the organisation.
- For all findings or vulnerabilities identified during the tests carried out will be generated and documented sufficient evidence to prove the existence of the same.
- The format of the evidence can be variable in each case, screen capture, raw output of security tools, photographs, paper documents, etc.
As a result of tests performed should generate a document containing at least the following sections:
- Introduction.
- Executive Summary.
- Methodology.
- Identified vulnerabilities.
- Recommendations for correcting vulnerabilities.
- Conclusions.
- Evidence.
23. Incident Response Plan
- 'Security incident' means any incident (accidental, intentional or deliberate) relating to our communications or information processing systems. The attacker could be a malicious stranger, a competitor, or a disgruntled employee, and their intention might be to steal information or money, or just to damage Mighty Group.
- The Incident response plan has to be tested once annually. Copies of this incident response plan is to be made available to all relevant staff members, and take steps to ensure that they understand it and what is expected of them.
- Employees of Mighty Group will be expected to report to the security officer for any security related issues
Mighty Group PCI security incident response plan is as follows:
- Each department must report an incident to the Information Security Officer (preferably) or to another member of the PCI Response Team.
- That member of the team receiving the report will advise the PCI Response Team of the incident.
- The PCI Response Team will investigate the incident and assist the potentially compromised department in limiting the exposure of data and in mitigating the risks associated with the incident.
- The PCI Response Team will resolve the problem to the satisfaction of all parties involved, including reporting the incident and findings to the appropriate parties (credit card associations, credit card processors, etc.) as necessary.
- The PCI Response Team will determine if policies and processes need to be updated to avoid a similar incident in the future, and whether additional safeguards are required in the environment where the incident occurred, or for the institution.
- If an unauthorised wireless access point or devices is identified or detected as part of the quarterly test this is should be immediately escalated to the Security officer or someone with similar privileges who has the authority to stop, cease, shut down, and remove the offending device immediately.
- A department that reasonably believes it may have an account breach, or a breach of data or of systems related to the PCI environment in general, must inform Mighty Group PCI Incident Response Team.
- After being notified of a compromise, the PCI Response Team, along with other designated staff, will implement the PCI Incident Response Plan to assist and augment departments response plans.
Mighty Group PCI Security Incident Response Team:
- CIO.
- Communications Director.
- Compliance Officer.
- Counsel.
- Information Security Officer.
- Collections & Merchant Services.
- Risk Manager.
- Incident Response Notification.
- Escalation Members.
- Escalation First Level.
- Information Security Officer.
- Controller.
- Executive Project Director for Credit Collections and Merchant Services Legal Counsel.
- Risk Manager.
- Director of Mighty Group Communications.
- Open Source Security Testing Methodology Manual.
- Mighty Group Managing Director.
- Executive Cabinet.
- Internal Audit.
- Auxiliary members as needed.
- External Contacts (as needed).
- Merchant Provider.
- Card Brands (if applicable).
- Internet Service Provider (if applicable).
- Internet Service Provider of Intruder (if applicable).
- Communication Carriers (local and long distance).
- Business Partners.
- Insurance Carrier.
- External Response Team as applicable (CERT Coordination Centre 1, etc.).
- Law Enforcement Agencies as applicable in local jurisdiction.
In response to a systems compromise, the PCI Response Team and designees will:
- Ensure compromised system/s is isolated on/from the network.
- Gather, review and analyse the logs and related information from various central and local safeguards and security controls.
- Conduct appropriate forensic analysis of compromised system.
- Contact internal and external departments and entities as appropriate.
- Make forensic and log analysis available to appropriate law enforcement or card industry security personnel, as required.
- Assist law enforcement and card industry security personnel in investigative processes, including in prosecutions.
- Mighty Group require no and has no access to cardholder data.
- If Mighty Group were in future duly authorised and fully PCIDSS compliant, then the following would apply.
- The card companies have individually specific requirements the Response Team must address in reporting suspected or confirmed breaches of cardholder data.
- Incident Response notifications to various card schemes.
- In the event of a suspected security breach, alert the information security officer or your line manager immediately.
- The security officer will carry out an initial investigation of the suspected security breach.
- Upon confirmation that a security breach has occurred, the security officer will alert management and begin informing all relevant parties that may be affected by the compromise.
VISA Steps
If the data security compromise involves credit card account numbers, implement the following procedure:
- Shut down any systems or processes involved in the breach to limit the extent, and prevent further exposure.
- Alert all affected parties and authorities such as the Merchant Bank (your Bank), Visa Fraud Control, and the law enforcement.
- Provide details of all compromised or potentially compromised card numbers to Visa Fraud Control within 24 hours.
For more Information visit:
This report must be provided to VISA within 14 days after initial report of incident to VISA. The following report content and standards must be followed when completing the incident report. Incident report must be securely distributed to VISA and Merchant Bank. Visa will classify the report as VISA Secret:
- Executive Summary.
- Include overview of the incident.
- Include RISK Level(High, Medium, Low).
- Determine if compromise has been contained II.
- Background.
- Include forensic tools used during investigation V.
- Findings.
- Number of accounts at risk, identify those stores and compromised.
- Type of account information at risk.
Identify ALL systems analysed. Include the following:
- Domain Name System (DNS) names.
- Internet Protocol (IP) addresses.
- Operating System (OS) version.
- Function of system(s).
Identify ALL compromised systems. Include the following:
- DNS names.
- IP addresses.
- OS version.
- Function of System(s).
- Time frame of compromise.
- Any data exported by intruder.
- Establish how and source of compromise.
- Check all potential database locations to ensure that no CVV2, Track 1 or Track 2 data is stored anywhere, whether encrypted or unencrypted (e.g., duplicate or backup tables or databases, databases used in development, stage or testing environments, data on software engineers machines, etc.).
- If applicable, review VisaNet endpoint security and determine risk.
- Compromised Entity Action.
- Recommendations.
- Contact(s) at entity and security assessor performing investigation.
- This classification applies to the most sensitive business information, which is intended for use within VISA. Its unauthorised disclosure could seriously and adversely impact VISA, its employees, member banks, business partners, and/or the Brand
MasterCard Steps:
- Within 24 hours of an account compromise event, notify the MasterCard Compromised Account Team via phone at 1-636-722-4100.
- Provide a detailed written statement of fact about the account compromise (including the contributing circumstances) via secured e-mail
to: compromised_account_team@mastercard.com
- Provide the MasterCard Merchant Fraud Control Department with a complete list of all known compromised account numbers.
- Within 72 hours of knowledge of a suspected account compromise, engage the services of a data security firm acceptable to MasterCard to assess the vulnerability of the compromised data and related systems (such as a detailed forensics evaluation).
- Provide weekly written status reports to MasterCard, addressing open questions and issues until the audit is complete to the satisfaction of MasterCard.
- Promptly furnish updated lists of potential or known compromised account numbers, additional documentation, and other information that MasterCard may request.
- Provide finding of all audits and investigations to the MasterCard Merchant Fraud Control department within the required time frame and continue to address any outstanding exposure or recommendation until resolved to the satisfaction of MasterCard.
- Once MasterCard obtains the details of the account data compromise and the list of compromised .account numbers, MasterCard will:
- Identify the issuers of the accounts that were suspected to have been compromised and group all known accounts under the respective parent member IDs.
◦ Distribute the account number data to its respective issuers.
◦ Employees of Mighty Group will be expected to report to the security officer for any security related issues.
◦ The role of the security officer is to.
◦ Effectively communicate all security policies and procedures to employees within Mighty Group and contractors.
◦ In addition to this, the security officer will oversee the scheduling of security training sessions, monitor and enforce the security policies outlined in both
this document and at the training sessions and finally,
◦ Oversee the implantation of the incident response plan in the event of a sensitive data compromise
◦ Discover Card Steps.
◦ Within 24 hours of an account compromise event, notify Discover Fraud Prevention.
◦ Prepare a detailed written statement of fact about the account compromise including the contributing circumstances.
◦ Prepare a list of all known compromised account numbers.
◦ Obtain additional specific requirements from Discover Card.
American Express Steps
- Within 24 hours of an account compromise event, notify American Express Merchant Services.
- Prepare a detailed written statement of fact about the account compromise including the contributing circumstances.
- Prepare a list of all known compromised account numbers Obtain additional specific requirements from American Express.
- Mighty Group require no and has no access to cardholder data.
- If Mighty Group were in future duly authorised and fully PCIDSS compliant, then the above card association rules would fully apply.
24. Roles And Responsibilities:
Chief Security Officer (or equivalent) is responsible for overseeing all aspects of information security, including but not limited to:
- Creating and distributing security policies and procedures.
- Monitoring and analysing security alerts and distributing information to appropriate information security and business unit management personnel.
Creating and distributing security incident response and escalation procedures that include:
- Maintaining a formal security awareness program for all employees that provide multiple methods of communicating awareness and educating employees (for example, posters, letters, meetings).
- The Information Technology Office (or equivalent) shall maintain daily administrative and technical operational security procedures that are consistent with the PCIDSS (for example, user account maintenance procedures, and log review procedures).
System and Application Administrators shall:
- Monitor and analyse security alerts and information and distribute to appropriate personnel.
- Administer user accounts and manage authentication.
- Monitor and control all access to data.
- Maintain a list of service providers.
- Ensure there is a process for engaging service providers including proper due diligence prior to engagement.
- Maintain a program to verify service providers PCIDSS compliant status, with supporting documentation.
The Human Resources Office (or equivalent) is responsible for tracking employee participation in the security awareness program, including:
- Facilitating participation upon hire and at least annually.
- Ensuring that employees acknowledge in writing at least annually that they have read and understand Mighty Group information security policy.
General Counsel (or equivalent) will ensure that for service providers with whom information is shared:
- Written contracts require adherence to PCIDSS by the service provider.
- Written contracts include acknowledgement or responsibility for the security of data by the service provider.
25. Third Party Access To Cardholder Data
- Mighty Group require no and has no access to cardholder data.
- Mighty Group are unable to provide any third party with access to any cardholder data.
- All third-party companies providing critical services to Mighty Group must provide an agreed Service Level Agreement.
- All third-party companies providing hosting facilities must comply with Mighty Group Physical Security and Access Control Policy.
- All third-party companies, including processing banks and payment gateway technology providers, which exclusively have access to cardholder information must:
- Adhere to the PCIDSS security requirements.
- Acknowledge their responsibility for securing the cardholder data.
- Acknowledge that the cardholder data must only be used for assisting the completion of a transaction, supporting a loyalty program, providing a fraud control service or for uses specifically required by law.
- Have appropriate provisions for business continuity in the event of a major disruption, disaster or failure.
- Provide full cooperation and access to conduct a thorough security review after a security intrusion to a Payment Card industry representative, or a Payment Card industry approved third party.
- Mighty Group require no and has no access to cardholder data.
- Mighty Group are unable to provide any third party with access to any cardholder data.
26. User Access Management
- Access to Mighty Group is controlled through a formal user registration process beginning with a formal notification from HR or from a line manager.
- Each user is identified by a unique user ID so that users can be linked to and made responsible for their actions.
- The use of group IDs is only permitted where they are suitable for the work carried out.
- There is a standard level of access; other services can be accessed when specifically authorised by HR/line management.
- The job function of the user decides the level of access the employee has to data.
- A request for service must be made in writing (email or hard copy) by the newcomer’s line manager or by HR.
The request is free format, but must state:
- Name of person making request.
- Job title of the newcomers and work group.
- Start date.
- Services required (default services are: Mail, Libre Office, Mozilla Firefox and Internet access).
- Each user will be given a copy of their new user form to provide a written statement of their access rights, signed by an IT representative after their induction procedure.
- The user signs the form indicating that they understand the conditions of access.
- Access to all Mighty Group systems is provided by IT and can only be started after proper procedures are completed.
- As soon as an individual leaves Mighty Group employment, all his/her system logons must be immediately revoked.
- As part of the employee termination process HR (or line managers in the case of contractors) will inform IT operations of all leavers and their date of leaving.
27. Access Control Policy
- Access Control systems are in place to protect the interests of all users of Mighty Group computer systems by providing a safe, secure and readily accessible environment in which to work.
- Mighty Group will provide all employees and other users with the information they need to carry out their responsibilities in as effective and efficient manner as possible.
- Generic or group IDs shall not normally be permitted, but may be granted under exceptional circumstances if sufficient other controls on access are in place.
- The allocation of privilege rights (e.g. local administrator, domain administrator, super-user, root access) shall be restricted and controlled, and authorization provided jointly by the system owner and IT Services.
- Technical teams shall guard against issuing privilege rights to entire teams to prevent loss of confidentiality.
- Access rights will be accorded following the principles of least privilege and need to know.
- Every user should attempt to maintain the security of data at its classified level even if technical security mechanisms fail or are absent.
- Users electing to place information on digital media or storage devices or maintaining a separate database must only do so where such an action is in accord with the data classification.
- Users are obligated to report instances of non-compliance to the Mighty Group CISO.
- Access to Mighty Group IT resources and services will be given through the provision of a unique Active Directory account and complex password.
- No access to any Mighty Group IT resources and services will be provided without prior authentication and authorization of a user’s Mighty Group Active Directory account.
- Password issuing, strength requirements, changing and control will be managed through formal processes. Password length, complexity and expiration times will be controlled through Active Directory Group Policy Objects.
- Access to Confidential, Restricted and Protected information will be limited to authorised persons whose job responsibilities require it, as determined by the data owner or their designated representative. Requests for access permission to be granted, changed or revoked must be made in writing.
- Users are expected to become familiar with and abide by Mighty Group policies, standards and guidelines for appropriate and acceptable usage of the networks and systems.
- Access for remote users shall be subject to authorization by IT Services and be provided in accordance with the Remote Access Policy and the Information Security Policy. No uncontrolled external access shall be permitted to any network device or networked system.
- Access to data is variously and appropriately controlled according to the data classification levels described in the Information Security Management Policy.
- Access control methods include logon access rights, file share and disk permissions, user account privileges, server and workstation access rights, firewall permissions, IIS Intranet/Extranet authentication rights, SQL database rights, isolated networks and other methods as necessary.
- A formal process shall be conducted at regular intervals by system owners and data owners in conjunction with IT Services to review users access rights. The review shall be logged and IT
- Services shall sign off the review to give authority for users continued access rights.
28. Wireless Policy
- Installation or use of any wireless device or wireless network intended to be used to connect to any of the Mighty Group networks or environments is prohibited.
- A quarterly test should be run to discover any wireless access points connected to Mighty Group network.
Usage of appropriate testing using tools like NET STUMBLER, KISMET etc. must be performed on a quarterly basis to ensure that:
- Any devices which support wireless communication remain disabled or decommissioned.
- If any violation of the Wireless Policy is discovered as a result of the normal audit processes, the security officer or any one with similar job description has the authorisation to stop, cease, shut down, and remove the offending device immediately.
If the need arises to use wireless technology it should be approved by Mighty Group and the following wireless standards have to be adhered to:
- Default SNMP community strings and passwords, pass phrases, encryption keys/security related vendor defaults (if applicable) should be changed immediately after the installation of the device and if anyone with knowledge of these leaves the Mighty Group.
- The firmware on the wireless devices has to be updated accordingly as per vendors release schedule.
- The firmware on the wireless devices must support strong encryption for authentication and transmission over wireless networks.
- Any other security related wireless vendor defaults should be changed if applicable.
- Wireless networks must implement industry best practices (IEEE 802.11i) and strong encryption for authentication and transmission of data.
- An Inventory of authorised access points along with a business justification must be maintained.
More Information
Please feel free to contact us if you require any further information.
Appendix A:
Agreement to Comply Form
Agreement to Comply With Information Security Policies
____________________________________________
Employee Name (printed)
____________________________________________
Department
I agree to take all reasonable precautions to assure that Mighty Group internal information, or information that has been entrusted to Mighty Group by third parties such as customers, will not be disclosed to unauthorised persons.
At the end of my employment or contract with the Mighty Group, I agree to return all information to which I have had access as a result of my position.
I understand that I am not authorised to use sensitive information for my own purposes, nor am I at liberty to provide this information to third parties without the express written consent of the internal manager who is the designated information owner.
I have access to a copy of the Information Security Policies, I have read and understand these policies, and I understand how it impacts my job.
As a condition of continued employment, I agree to abide by the policies and other requirements found in Mighty Group security policy.
I understand that non-compliance will be cause for disciplinary action up to and including dismissal, and perhaps criminal and/or civil penalties.
I also agree to promptly report all violations or suspected violations of information security policies to the designated security officer.
________________________
Employee Signature
________________________
Date
Appendix B
Redacted from online version of this policy for security reasons.
List of Service Providers
Name: Wix
PCIDSS Compliant?: Yes
Most Recent Information: https://support.wix.com/en/article/security-of-wixs-billing-services-and-pci-compliance
Name: Amazon Web Services
PCIDSS Compliant?: Yes
Most Recent Information: https://aws.amazon.com/compliance/services-in-scope/