Showing posts with label infosec. Show all posts
Showing posts with label infosec. Show all posts

Wednesday, 16 May 2018

INTRODUCTION & CHANGES IN PCI-DSS v3.2


INTRODUCTION & CHANGES IN PCI-DSS V3.2


The Payment Card Industry Data Security Standard (PCI- DSS) was developed to follow the policy and standards of cardholder data security which consistent data security measures globally. PCI- DSS provides a minimum of technical and operational requirements to protect data of the cardholders. PCI -DSS applies to all operation which involved in payment card processing of cardholder data.
The below describes the changes in PCI-DSS v3.2 from version 3.1.

AREAS EMPHASISED IN V3.2:

  • CHANGE MANAGEMENT PROCESS:

    • The Change Management Process is done to perform the secure changes during the process based on the business requirement.
  • ADMINISTRATIVE ACCESSING:

    • The Administrative privilege is given only to the single user were the particular can gain the read, write and execute access to the changes in the environment.
  • INCIDENT RESPONSE:

    • Incident response is nothing but when there is an issue raised in the environment the action is taken based on the severity of the problems.
  • E-COMMERCE – A-EP ENVIRONMENTS:

    • the “Expected Testing” column is based on the testing procedures in the PCI DSS and provides a high-level description of the types of testing activities should be performed to verify that a requirement has met.

SAQ VERSION
# QUESTIONS V3.1
# QUESTIONS V3.2
DIFFERENCE

SAQ D-SP347369+22
SAQ D-MER326331+5
SAQ C139162+23
SAQ A-EP139193+54
SAQ B-IP8384+1
SAQ C-VT7380
+7
SAQ B41410
SAQ P2PE-HW3533-2
SAQ A1422+8

MASKING THE PAN NUMBER

  • DISPLAYING THE PRIMARY ACCOUNT NUMBER

    • First six and last four digits of PAN can be displayed based on the current requirement.
For a legitimate business need the pan number must be encrypted. Follow Requirement 3.3 for further reference.

CHANGE CONTROL

  • CHANGES IN CHANGE CONTROL IN V3.2

    • Maintain proper documentation when any change control issued.
    • Implement all the necessary control in all the new and existing systems or devices.
    • Change control processes must include verification of PCI DSS requirements impacted by a (significant) change. Fallow Requirement 6.4.6 which is effective from Feb 1, 2018.

HIGH-RISK VULNERABILITY MANAGEMENT

  • INTEGRATE VULNERABILITIES INTO THE RISK ASSESSMENT PROCESS

    • Ensure all “high risk” vulnerabilities must be addressed for internal scans and resolved.
    • By the vulnerability ranking as per Requirement 6.1 and 6.2 in PCI-DSS scope.
    • After resolving the vulnerabilities ensure the risk has been cleared by rescanning.

REMOTE ADMINISTRATOR ACCESS TO CDE

  • ANY NON-CONSOLE ADMINISTRATOR ACCESS TO CDE

    • All the non-console access into CDE for personnel with administrative access must implement the multi-factor authentication.
    • The current requirement for multi-factor authentication for remote access to CDE for personnel with administrative access still applies according to the PCI-DSS scope.
    • Fallow PCI-DSS scope 8.3.1 and 8.3.2 mandatorily from Jan 31, 2018.

RESOURCE

  • Refer the following document for the PCI-DSS scope.
  • LINK: pcisecuritystandards.org/document_library?category=pcidss

AUTHOR

Dharmesh B
Security Engineer
Briskinfosec Technology and Consulting Pvt Ltd.,
https://www.linkedin.com/in/dharmeshbaskaran/

Monday, 23 April 2018

HTML INJECTION ATTACK

HTML INJECTION ATTACK


INTRODUCTION:

HTML injection is an attack which occurs in web applications that allows users to insert an HTML tag attributes via using any specific parameters like,  <h>, </h1>, <td>, <tr>, <a href> tags are used as one of the sources to perform this HTML based injection attack.
These strategies provided with untrusted input, at that point there is a high risk of XSS, specifically an HTML injection one. If strings not sanitised efficiently, the issue could prompt XSS based HTML injection. This HTML injection could lead the attacker to modify the web content easily.

POSSIBLE ATTACK SCENARIO:

In this way, how we can perform an HTML injection attack using the following steps,
  •  In this beginning process, an attacker can find the injection flaw and try to make an HTML injection attack.
  • Attacker crafts the malicious links, including his infected HTML injection code and sends it to a client through an email
  • When the client visits the web page because of the page located within a trusted domain
  • The attacker can inject an HTML code is rendered and presented to the client requesting valid credentials like username and password
  • The client enters a username and password, which are both sent to the attacker server.
HTML injection attack also have two different types, there are
  • stored HTML injection attack
  • Reflected HTML injection attack

STORED HTML INJECTION ATTACK

In this stored HTML is also known as persistence (always stored in the backend database), the attacker can give the credentials inserting in the web server it can be stored in permanently, and the application server gives out it to the user when the user visits the targeted website. Here I have to give a sample HTML code for the stored HTML injection.
When the client clicks the payload, it gets redirected to the official part of the website; the injected HTML code will get executed by the browser.

REFLECTED HTML INJECTION

The reflected HTML is known as Non-persistence (It does not store in the backend database, it will get immediately indicated). Whenever the backend server processes any HTML input without proper sanitisation and validation of the given HTML input,  it will lead to HTML injection in the web application.

Here I have to give the input like <h>you are hacked</h>, and it will reflect as ‘you are hacked “ class=” colourbox” title=” help me with page”>

MITIGATION FOR HTML INJECTION:

Here we used parameterised queries to block unwanted scripts for the HTML injection using special characters like <, >, “, ‘, %, &, / to appropriately sanitised in the given input fields. The favoured choice is to utilise a protected API which stays away from the utilisation of the translator entirely or provides a parameterised interface. Be careful of APIs, for example, put away methods, are parameterised.
If a parameterised API isn’t accessible, you should carefully escape unique characters utilising the appropriate escape grammar for that translator.

CONCLUSION:

HTML injection is similar to cross-site scripting vulnerability (XSS), which affects the client side. So, HTML injection can exploit in the same way as that of cross-site scripting which includes adding HTML data to the web application, temporary defacement of website etc… hence it is necessary to prevent web applications from HTML injection.

AUTHOR

Aravindan S
Security Engineer
BriskinfoSec Technology and Consulting  Pvt Ltd.,
https://www.linkedin.com/in/aravindhan-s-90b98787/

Thursday, 19 April 2018

PCI-DSS VS ISO 27001 STANDARDS



PCI-DSS VS ISO 27001 STANDARDS


INTRODUCTION:

PCI-DSS and ISO 27001 are organized in sets of requirements for the cardholder data process. PCI-DSS has 12 sets of elements; there are about 250 controls based on securing credit card information. In ISO 27001, there are 11 sets of elements with 114 controls based on improving an ISMS, planning, running, implementing, monitoring. In this article, I’m going to discuss and examines the interoperability of PCI-DSS and ISO/IEC 27001 and also some of the pros and cons of the PCI-DSS and ISO/IEC 27001 standards.

PCI-DSS STANDARD:

PCI-DSS is a standard of data security for the credit card organizations, and it also applies only to companies that have the process, store, or transmit credit card data. Compliances with the standard are mandatory, though depending on the full range of cards processed. PCI-DSS is a card data security standard developed by a council consisting of Visa, MasterCard, American Express, Discover and JCB to protect the payment card and cardholder’s sensitive information processed by organizations.

ISO 27001 STANDARD:

ISO 27001 is a standard that includes seven main titles within the scope, such as organization, leadership, planning, support, operation, performance evaluation and improvement. It’s a worldwide recognition, which lays down the requirements for the establishment of an ISMS. It applies to any organization.

HIGH-LEVEL MAPPING OF PCI AND ISO27001
PCI-DSS REQUIREMENTS
ISO27001 CLAUSE
1. Install and maintain a firewall configuration to protect cardholder data.A-12: Operations Security
A-13: Communications Security
2. Do not use vendor-supplied defaults for system passwords and other security parameters.A-12: Operations Security
A-13: Communications Security
3. Protect stored cardholder data.A-12: Operations Security
A-13: Communications Security
4. Encrypt transmission of cardholder data across open, public networks.A-14: System acquisition, development and maintenance.
5. Protect all systems against malware and regularly update antivirus software or programs.A-14: System acquisition, development and maintenance.
6. Develop and maintain secure systems and applications.A-14: System acquisition, development and maintenance.
7. Restrict access to cardholder data by business need to knowA-12: Operations Security
A-13: Communications Security
8. Identify and authenticate access to system components.A-12: Operations Security
A-13: Communications Security
9. Restrict physical access to cardholder data.A-11: Physical and environmental security
10. Track and monitor all access to network resources and cardholder data.A-12: Operations Security
A-13: Communications Security
11. Regularly test security systems and process.A-14: System acquisition, development and maintenance
A-6: Organization of Information security
A-18: Compliance
12. Maintain a policy that addresses information security for all personnel.A-5: Information security policies

COMPARISON OF PCI-DSS AND ISO 27001

It is recommended and required that both PCI-DSS and ISO27001 provides better solutions for risk management to Card data Industry and other organizations. The ISO 27001 is better than that of PCI-DSS standards as all the controls have been written at a high level. There are compliance levels in PCI-DSS to measure the maturity level of the company, but no compliance levels exist in ISO 27001. “The organizations have to determine the boundaries and applicability of the information security management system to establish its scope.” When comparing the scope of the two standards, scope selection in ISO/IEC 27001 depends on the company; however, the scope is exactly the credit cardholder information in PCI-DSS.
The controls in ISO 27001 are a suggestion to all the organizations, and also it is important to note that the controls in PCI-DSS standards are mandatory to payment and Cardholder data organizations.
Were the ISO 27001 contains more requirements than PCI-DSS, it is easier to comply with the ISO 27001 standard to the organizations.
According to the costs, establishing a partial (ISMS) audit and PDCA cycle which cost more to the organization as it a mandatory.
In an organization, the re certification auditing of ISO 27001 is performed in every three-year cycles, and internal scope auditing is conducted. There are also surveillance audits that are done at least once. In every PCI-DSS auditing, there are four network scanning audits and a Level 1 onsite audit.
MAPPING OF PCI-DSS AND ISO 27001
PARAMETER
ISO27001
PCI-DSS
CreatorISOPCI Council
FlexibilityHighLow
ScopeDepends on the companyCredit cardholders information
Controls appliedFlexibleTight
ControlsHigh-LevelLow-Level
ComplianceEasyHard
Number of Controls114224
AuditingThree-year cycles and a small-scope audit performed every yearFour network scanning audits and an onsite audit for level 1
CertificationMaybe given to all companiesAny companies that provide information security for critical paying processes
Compliance levelDoes not existExists

CONCLUSION:

PCI-DSS is a standard which handles Security for Cardholder data, whereas ISO 27001 is a specified to the Information Security and Management of the Organization. Mapping of PCI-DSS and ISO/IEC 27001 standards is optional information for managers who are assigned with ensuring to either standard in their organizations. It is recommended that PCI-DSS and ISO/IEC 27001 must be combined to give a better solution to risk mitigation and secure the organization of Cardholder data.

REFERENCE:

AUTHOR

Dharmesh B
Security Engineer
Briskinfosec Technology and Consulting Pvt Ltd.,
https://www.linkedin.com/in/dharmeshbaskaran/

Thursday, 12 April 2018

GDPR (GENERAL DATA PROTECTION REGULATION)


GDPR (GENERAL DATA PROTECTION REGULATION)



GDPR is the General Data Protection Regulation, adopted on April 27, 2016, and it will be valid from May 25, 2018. The GDPR replaces the EU’s Data Protection Directive, and this method is mainly used by European Union member’s to protect their Data.GDPR is primarily used to control the Data Breach, Data portability on EU member’s and followed by this other countries are started to develop GDPR for their Data Protection but this method can also be used to store the personal data, or other data’s comes under the national security organisations.

DATA’S PROTECT UNDER GDPR:

  • Necessary Identity information such as name, address and ID numbers
  • Web Data such as location. IP address and cookie data
  • Health and generic Data
  • Biometric Data
  • Political Opinion etc.

GDPR OVERALL ARCHITECTURE:

Here the overall architecture diagram of the GDPR is described, and it starts from the significant executive team followed by legal advisories (adopted by a required organisation to cross-check the process) and to the IT and software development of mainly follows. GDPR under CIA triad is called Confidentiality, Integrity and Availability to protect their required data.The outcome of the products is checked by the Product Development Team.Finally, CISO and information security follows data privacy method to process the data in a secured manner and later it gets process by the data analyst and reaches the market that’s the overall process of the GDPR takes place and  refer the below link  to follow the GDPR checklist for better data protection

GDPR IN CYBERSECURITY:

Most of the Cybersecurity Organization’s falls under the network, endpoint protections and they also prevent us from the unauthorised access, threat management, and Vulnerability assessment etc. and cybersecurity in GDPR takes place by its method called data encryption, and data pseudonymization. Data encryption is the process that collects the whole data and changes it to the code and stores it in an encrypted way. unless you entered the critical value, you could not access the data and data pseudonymization is the method to add additional data subject to your old data ’s, data masking for better security or hashing can be done here to protect your data’s
Data breaches in cybersecurity organisations can be controlled by GDPR and So, consider investing in Cyber Essentials, a certification scheme backed by the British government to help organisations to prevent online attacks and hacking. This will assist with compliance with the GDPR, as well as improving the security of your company, customers and partners.
Sans generates a compliance report for GDPR which has to be followed by every organisation to secure your data, and by this, you can also trap the path of where mainly data breaches take place

DETECT AND BLOCK THREATS IN ATTACK CYCLE:

Security tools used in the cybersecurity organisation is used to test your existing vulnerability and risks, and here by using GDPR you can set some conditions to protect your data, and they are by the below techniques as follows.

FIRST LOOK AT EXPOSED PRIVILEGED ACCOUNTS:

When unconstrained delegation has been enabled it leads an attacker to connect to your machine and by this ticket granting ticket will be stored and it leads to compromise and control a domain controller

IDENTIFY CONTROLS THAT CAN BYPASS PRIVILEGED ACCOUNT SECURITY:

How many of you know that all your privileged accounts are safe? First, you have to check for every privileged account and secure the required account with some password or with some encryption methods, and by then it will be difficult for an attacker to bypass your account.

IDENTIFY AUTHENTICATION FIELDS TO YOUR ACCOUNT:

Check for the authentication field in your account that can be easily bypassed, e.g. Kerberos authentication or another authentication process. These flaws attacker can easily access your account and can gather any information’s and also set encryption for your account to protect your data, and by this, it can also secure you from unauthorised access.

GDPR IN PENETRATION TESTING:

The Overall Cybersecurity breach of 2017 was about 61% holds personal data on their customers electronically, and about 46% of all UK business identified at least one cybersecurity breach or attack in the past 12 months. GDPR in CREST certificate launched for network infrastructure, and here by this, an attack can process the cardholder environment.
Refer the above link to process GDPR toolkit guides to follow for every organisation to prepare GDPR data protection

OVERALL STATISTICS OF GDPR:

C GDPR is the official course offered by the IT governance and want to get certified in GDPR refer the link as follows.

CONCLUSION:

I’m Sure that we have discussed something about GDPR data protection and also about its significant role in cybersecurity and follow the GDPR checklist to secure data protection for your organisation “are you waiting for the better data protection and we are also waiting for it.”
Reference Links:

AUTHOR

RamKumar
Security Engineer
BriskInfosec Technolagy And consulting PVT LTD
follow me @https://www.linkedin.com/in/ram-kumar-3439b511a/