‫ اخبار

صفحات: 1 2 3 4 5 ... » »»
نتایج جستجو براساس برچسب: «مقالات»
Developing and Assessing your DLP Strategy (Part 5)

Number: IRCAR201510281

Date: 2015-11-21

DLP tools

DLP solutions can consist of a number of different tools such as data discovery tools, network tools, monitoring tools, reporting tools, etc.

Data discovery is a very important element of data loss and leakage prevention because you can’t protect the sensitive information if you don’t know which information is sensitive and where it is located – and that means all copies, not just the primary copy. One thing that a good data discovery tool can do is find unencrypted data and then carry out your policies by automatically encrypting the data, removing it, notifying the data owner and/or stakeholders, or other action that you specify. In addition to detecting unencrypted individual files, it can find those shares/folders that are not encrypted and move the data to a location that has better access controls or encrypt the data in its current location.

Remember that data discovery is not just a one-time process. You can set your DLP tools to continuously scan for sensitive data, you can do it at pre-determined intervals such as daily, weekly or monthly, or you can perform data scanning on demand, for example in preparation for or as part of a security audit or in response to a known or suspected change in the data status.

Whereas discovery tools are focused more on data within the organization’s network, network tools can be used to identify sensitive data that is about to leave the network and ensure that it is encrypted while in transit. Remember that different encryption technologies are used to encrypt data at rest vs. data in transit; in the latter case you want to encrypt not just the data itself but the channel over which it is transmitted.

Monitoring tools can log who accesses (or attempts to access) data that has been classified as sensitive, and can record any changes that are made to the data itself, to its metadata, permissions, and so forth. Monitoring tools can detect when sensitive data is copied, moved or deleted, as well.

Reporting tools are capable of taking the information that is collected by the monitoring tools and putting it into usable and easily understandable format for the use of administrators, auditors, and managers. Reporting features can generate incident reports when DLP policy violations are detected and allow you to set alerts to automatically email or otherwise notify admins of the situation so that you can remedy it as quickly as possible.

DLP best practices in a “mobile first, cloud first” era

Mobility and the cloud bring heretofore unheard-of convenience for users but they complicate the lives of those charged with maintaining security. Data loss and leakage prevention in a mobile + cloud world has many inherent challenges, not the least of which is the shift of focus from protecting just the network to protecting the endpoints.

The biggest challenge is how to protect the data without unduly restricting what users can do. In the past, IT often took a “scorched earth” approach to security, locking down everything and allowing users as little leeway as possible on the premise that it’s better to be safe than sorry. In today’s BYOD, telecommuting, team-oriented business environment, that’s no longer desirable or even possible.

Today’s DLP solutions must now be able to protect data according to corporate policies even when that data is on devices that are outside of the corporate network. This means managed devices. Endpoint DLP relies not on just one technology but a combination: host-based firewalls, anti-malware software, encryption, rights management, content-aware USB/removable media controls, and so forth.


Here in Part 3 of our series of articles on how to go about developing an effective data loss and leakage prevention strategy, we took a look at the third element that impacts planning for DLP: practices. In the fourth and final installment in this series, we will focus on the last and in many ways the most important element: people.



2 آذر 1394 برچسب‌ها: مقالات
Your online life after death

Number: IRCAR201510279

Date: 2015-10-16

OK, so I know you don’t really want to talk about this – but here goes: we’re all going to die someday. Maybe you’ve already started thinking ahead:

- planning for your funeral,

- the care of loved ones and

- disposal of your property.

But what about your online life? All the digital files, photos, posts and other accounts you leave behind might cause a lot of inconvenience – even fraud or identity theft – for your loved ones to clean up.

The key to digital life after death, or even after incapacity, is planning. Think about your digital life and what you want to happen to each part of it when you can’t handle it yourself.

Here are a few tips to figure out a plan for your online life after death.

• Count your accounts. Make an inventory of your digital life, including accounts for email, social media, blogging, gaming, and cloud storage. Keep track of each site’s name, URL, your user name, password, your wishes for each, and other information that might be necessary for access. In that inventory, describe your wishes for those accounts: preserve, delete, secure the value or whatever else is appropriate.

Of course, compiling this inventory creates risk in and of itself, so keep your inventory secure and out of plain sight. Some of your accounts may involve money – either real-world or online currencies – and may require additional attention. Keep your inventory secure and out of plain sight. Don’t attach your inventory to your will which becomes a public document after your death. Keep your inventory secure and out of plain sight.

• Secure It All. Now that you have a master collection of everything that exists in your digital life, you need to make sure it’s secure. If you’re using the digital options, you need to use more than just a strong password. Nowadays, there are countless online services for storing passwords. Be aware that even the most secure systems are vulnerable to hacking. If you're interested in going this route, investigate a service's features, ease of use, customer support and, most importantly, its security.

If you don’t want to use any digital option, then simply write everything down on paper. I would highly advise against using a program like Word and then printing the file. The main issue being that while you are creating the file, it’s wide open to attack and not encrypted. Plus you have the chance of forgetting about it altogether, thereby opening yourself up to all kinds of problems. It will obviously take quite a bit of time to compile the list, so it’s best to use something secure while you do it.

At a later point, after exporting the database to a printed version, you could delete the database or online account if you really felt uncomfortable.

• Get in the know – now. Many accounts will let you make arrangements now or name someone to manage the account after your death. Research your options.

• Who can help? While the inventory of digital assets is critical, you also need the right person to access those accounts and carry out your wishes. And then give them the roadmap to your digital life and the legal power to act for you. You might want to name a digital executor to handle all these tasks after your death, preferably someone who has experience with online accounts and will understand how to carry out your instructions – or make decisions about issues that you might not have foreseen. You can select a friend or family member to be your digital executor or you can hire a third-party service to help you.

13 آبان 1394 برچسب‌ها: مقالات
Developing and Assessing your DLP Strategy (Part 4)

Number: IRCAR201510278

Date: 2015-10-23


A data loss and data leakage prevention strategy is a must for any organization that creates, uses, stores, moves or accesses any type of data that is sensitive, confidential or falls under regulatory privacy protection mandates. In Part 1 of this multi-article series, we provided a high level overview of what DLP is, some of the possible consequences of data loss or leakage, and the essential elements of an effective DLP strategy.

In Part 3, we started to delve more deeply into the intricacies of DLP, characteristics of good DLP software solutions, discussing two of four important elements: policies and programs.

DLP best practices

In Part 2, we talked about how you need to identify and categorize the types of sensitive data that you want to protect, and how software monitoring and alerting can detect sensitive data that is at risk and notify you, and/or technologically enforce the data protection rules that you set up. But it’s not enough to just configure monitoring and then “set it and forget it”. Data loss and leakage protection is an ongoing process and it’s important to ensure that it’s properly implemented to begin with and that it adapts as your data protection needs grow and change.

Basic Guidelines

Some guidelines to follow in implementing a DLP solution include:

· If you fall under regulatory compliance mandates, identify the governing bodies, statutes and/or industry rules that are applicable to ensure that your DLP strategy will comply with their requirements regarding protection of sensitive data.

· Identify and categorize sensitive data that needs protecting prior to choosing and deploying your DLP solution, as this will aid you in making the selection and determining the best deployment strategy. In particular, determine the file types and formats in which the data is stored so you can ensure that the DLP solution you select supports those formats.

· Ensure that your comprehensive solution will cover sensitive data at all stages: data at rest, data in transit and data in use.

· Create a test environment to allow you to evaluate the effectiveness of your solution and detect problems, identify false positives, etc. This will make it possible to test and fine tune your policies and procedures without disrupting the business process.

· Educate data owners, data stewards and data custodians as well as all of those who will access or manipulate the data and include your compliance team, human resources and business units that are impacted by the data.

· Ensure that you have safeguards against “data drift,” the unintentional and/or unauthorized moving or copying of sensitive data to unprotected devices via email, through BYOD devices and telecommuter access, removable media, etc. and even through data backup mechanisms that copy data to locations without strong controls.

· Regularly update risk profiles.

· Establish a procedure for documenting DLP incidents.

Your DLP solution should be “content aware” – that is, according to Gartner’s definition, it should enable you to apply policy dynamically based on the content and context at the time of an operation.



4 آبان 1394 برچسب‌ها: مقالات
Developing and Assessing your DLP Strategy (Part 2)

Number: IRCAR201510276

Date: 2015-10-

Policies, Programs, Practices and People

Your data loss and data leakage prevention strategy will revolve around four major components (all of which just happen to start with a P, which makes it a little easier to remember):

· Policies. Before you can implement a system for enforcement of data loss and data leakage prevention, you have to determine what to enforce. Some organizations look first at DLP software solutions, but I put policies as the first step because unless you know specifically what you want to accomplish with your DLP solution, it’s difficult to evaluate the different packages and know which one(s) can best handle your needs.

· Programs. Data loss and data leakage prevention software can take many forms. Some vendors attempt to provide an all-in-one turn-key solution. DLP can also be accomplished by the implementation of different solutions at different layers – network edge, server, endpoints – and a comprehensive DLP strategy is likely to include a number of solutions working together.

· Practices. Best practices can make or break the effectiveness of your DLP solution. This refers to how your DLP solution is architected, configured and managed.

· People. The human factor is always present in any security-related issue, and data loss/data leakage prevention is no exception. The people involved include your end users who legitimately have access to your data, unauthorized users whose intent it is to access your data (both insiders and outside attackers), and you and the other network administrators and security professionals who are tasked with protecting that data, along with your organization’s managers and executives and perhaps directors who make decisions that impact your DLP strategy.

Now we’ll look at each of the above components in more detail.

Policies: The Foundation of your DLP Strategy

The creation of your DLP policies is the two-part process of deciding the rules that will govern the detection of sensitive information and the implementation of controls to protect it when it is detected.

For example, you might want to identify the following types of information as sensitive/personal information, the privacy of which must be protected (by law, if you operate in certain regulated industries):

· Driver’s license numbers

· national ID card numbers

· Passport numbers

· Health services/medical account numbers

· Credit and debit card numbers

· Employer Taxpayer identification numbers

· Bank account numbers

· IP addresses

These are just a few of the types of numerical information that constitute sensitive personal data, the transmission of which outside your network you might logically want to restrict or at least monitor. But how do you identify these and differentiate them from other, non-sensitive strings of numbers?

That’s where DLP software comes in.

Programs: To Detect and Protect

A good DLP solution will include software that can check for patterns indicating that the types of information for which you’ve set up monitoring has been detected. It will be usable in either of two modes:

· Monitor and alert mode. The software will scan for sensitive data that is in danger of being exposed and will notify you.

· Enforcement mode. The software will apply rules that you specify to block or remove sensitive data that is being sent or shared in violation of the policies you have set.

The software can identify sensitive information in a couple of different ways. The rules for detecting well-defined information types such as social security or credit card numbers are relatively simple. It’s more difficult to identify, for example, a particular type of company document that you want to protect, such as the company’s financial statement. There is a software would evaluate the entire document and look for a group of pattern types instead of just one.

Good DLP software will allow you to customize the built-in sensitive information types. This allows you to apply policies that are specific to your organization or to a particular set of regulatory rules. Depending on the DLP software, writing your own policy templates may or may not require some programming skill.

Your DLP software should be able to scan and inventory all of the different types of data in different locations that we discussed in Part 1 of this series. If your organization stores some or all of its data in the cloud, your DLP solution must be able to detect and protect sensitive information both on local systems and in the cloud. Two of the most common points of data loss or leakage or web sites and email.

Part of the problem that makes it difficult for DLP software (and security in general) is that employees today, thanks to BYOD and cloud services, enjoy a very fluid online environment in which work and personnel lives are intertwined. Many employees use their personal email accounts in addition to their official corporate accounts when sending work related messages to colleagues. These are often web mail accounts such as Gmail, Hotmail/Outlook.com or Yahoo mail, which can further complicate your DLP efforts.

Your DLP software should be able to detect sensitive data sent via SMTP, HTTP, HTTPS, NNTP, FTP, IM, and so forth, as well as custom protocols (identified by port). Good DLP software will be able to block messages containing sensitive data and/or remove sensitive data from web sites.

Of course, in today’s litigious business world, detecting and protecting is not enough. Your DLP software must also be able to provide you with documentation of the actions that it takes. Logging and reporting is an increasingly important feature in all security-related software. You need to be able to generate reports in various formats to allow you to review incidents and remediate risks based on analytics.

Finally, your DLP software should integrate with your other security solutions for optimum protection and performance. For example, it needs to be able to integrate with your backup software to scan backups for sensitive data, with your endpoint protection software, your mobile device management software and so forth.



20 مهر 1394 برچسب‌ها: مقالات
Assessing the Security of Mobile Applications (Part 3) - The Test Methods and Outcomes

Number: IRCAR201509275

Date: 2015-09-29

Test Methods

A varied set of test methods can be used for application vetting. Through this app testing/app manipulation process organisations will establish whether the application in question does or does not support the organisations security requirements (covered in part two).

All layers should be covered when testing is undertaken, from the client layer, code and user interface through to the server layer, as all areas could potentially harbour security vulnerabilities.

Methods used for some time, like Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST), have been adapted for mobile application testing purposes. Behavioural testing, analysis of a running application, for mobile applications is also now routinely used and can uncover valuable information.

A multiple set of test tools will be necessary for a more thorough and comprehensive testing process. One tool type may be superior at ascertaining a particular requirement but might be poor at another. Time and consideration should be given to the best tool set suited to your application testing in order to achieve the most successful level of testing possible.

Test methods could include:

  • Correctness testing
  • Source or binary code analysis
  • Static or dynamic analysis
  • Manual testing
  • Automated testing

Test Method


When to choose this test method

Advantages/Disadvantages of method

Software correctness testing

Execute a program with intent to find errors

To approve the quality of the application

To evaluate the dependability of the application

To confirm the applications depicted functionality

To uncover security vulnerabilities

This type of testing is usually constructed on the unique specifications of the application to be tested. Improving the testing for vulnerabilities that may be unique to a specific application, rather than a more general testing approach with more generalized results.

Source or binary code analysis

Analyse source code or binary code using various methods and tools.

Manual approach-physically reviewing the code files

Automated approach-using automated static analysis tools

Skills and knowledge of development and domains for application security is extremely important for this type of analysis to be undertaken accurately and successfully

When the source code is available, to review the source code and find vulnerabilities in the source code.

When application is open source.

Also to confirm analyser results.

A variety of tools can be utilised (manual or automated approach)

Static analysis

Examines code

Involves app behaviour analysis

Reverse engineering is often required if source code is not available

To contemplate all potential scenarios that may arise when application is running

To analyse behaviour of applications and look for any exploitable weaknesses

Accurate Assurance is achievable for how the application will behave irrespective of application input or the environment in which it is run

Reverse engineering of code can be complex depending on the code type

Reverse engineering is useful to allow people to review the code

Dynamic analysis

Input analysis

Considers assorted use cases through varied input and analyses application conduct under the differing input scenarios

Use emulator or executing app or both

To see the working of the code as it is executed

Time consuming due to numerous potential input scenarios

Accuracy is questionable as you can’t guarantee that every scenario has been covered and complete code analysis is unlikely

Utilising both emulators and physical devices reduces the number of false negatives

Manual testing

Test For applications vulnerabilities with human input and analysis

Test For applications vulnerabilities manually

Time consuming

Requires a good knowledge base and skill set and experience

Automated testing

Test for application vulnerabilities

Uses Simulator or remote device access

Tool Types include:

  • Data-driven testing tools
  • User interface-driven testing tools
  • Fuzzing tools
  • Fault injection tools
  • Network testing tools
  • Penetration testing tools

To test for vulnerabilities using a variety of automated tools

Receive a report and risk assessment

Table 1

After all the work you’ve undertaken to achieve your results you may feel obliged to keep those results for yourself. However it is highly recommended that sharing of results through a software assurance community database is greatly beneficial. Through doing this security professionals and organisations could benefit from the collective efforts, reducing costs and time.

Reporting of the results and risk assessments is a critical area. Results should be reported intuitively and in a way that is easy for the auditor to understand and interpret.

App Approval or Rejection

A procedure should be set up prior to app vetting for the handling of an approved or rejected application. This should form part of the organisations policy procedures for app security. This is necessary so that the steps for the implementation or removal of the app are clearly clarified and can be easily followed after a decision of approval or rejection is made.

An auditor/s (more than one auditor is recommended for a more conclusive result) should decisively consider the results obtained within the assessment report and the level of risk association with utilising the app, in respect to the enterprises function and initially stipulated security requirements to see if these requirements have been supported by the app and then make a recommendation for app approval or rejection.

The auditor will use and consider the following criteria to come to a decision:

  • Perceived level of risk if the app were to be approved and utilised
  • Consider the apps security posture
  • Consider the organisations risk threshold
  • Consider the organisations vetting requirements and whether they have been supported of not
  • Consider the reports and risk assessment app test outcomes
  • Consider data type that will be processed
  • Consider how critical the app is to the enterprise
  • Consider who will use the app
  • Consider the environment in which the app will be used or located and the type of hardware it will require
  • Consider application documentation and service level agreements

Ultimately it is the organisations decision to finally decide whether to approve or reject the application. The individual or team within the organisation responsible for the final approving or rejecting procedure should take this recommendation into consideration along with the other business criteria related to the potential utilisation of the app (not based on the security of the app).

The procedures for implementing or removing the app depending on if the app is approved or rejected must then be undertaken.



20 مهر 1394 برچسب‌ها: مقالات
Developing and Assessing your DLP Strategy (Part 1)-section 2

Number: IRCAR201509273

Date: 2015-09-16

The consequences of data loss or leakage

You might think, given the statements above, that creating an effective data loss prevention strategy is a lot of work – and you would be right. However, it’s worth it, because the consequences of data loss can range from annoying to catastrophic. The damage is multiplied if you deal with particularly sensitive information and/or if you operate in a regulated industry.

In some fields, such as healthcare, data loss could literally be a life or death matter, and in others, such as military defense, the national security of an entire country could hang in the balance. For most organizations, the consequences of data loss won’t be quite as dire as this, but could still have a profound effect on the company’s bottom line and even its very continued existence. Consequences of the loss or unauthorized exposure of data could include:

  • Down time and loss of productivity
  • Damage to the company’s public reputation
  • Loss of clients or customers and thus loss of market share
  • Loss of faith in the business by investors, resulting in decreased market value
  • Loss of status/reputation within your industry
  • Loss of certifications, licenses, ratings, etc.
  • Fines or other penalties for compliance failure or violation of statutes or administrative regulations
  • Decreased revenues leading to financial instability and even bankruptcy

That is a pretty serious list to contemplate. We all know that an ounce of prevention is worth a pound of cure and in the case of data loss, there may be no cure.

Elements of an effective DLP strategy

Now that we understand both the consequences of data loss or leakage and some of the most common ways by which data is lost or leaked to unauthorized persons, we can start to formulate a strategy for prevention. We can start with determining where the data that needs to be protected is located, keeping mind that data moves and also that copies of the same data may (should) be in at least two different places.

Basically, we need to look at protecting data in the following locations/situations:

  • Data that resides on endpoint devices. This includes data that is created or residing temporarily or permanently on workstations or servers within the local network as well as that which is created or residing on computers, tablets or smart phones of mobile workers.
  • Data in storage (also called data at rest). This includes data that is stored on file servers, network attached storage systems, storage area networks, USB sticks, flash memory cards, optical discs, magnetic tape and other media, including backup copies of data and temporary files that hold data from various applications.
  • Data in transit (also called data in motion). This includes data that is in the process of being sent, copied or moved over the local network or across the Internet.

Intrusion and Extrusion Prevention

Intrusion detection systems (IDS) and intrusion prevention systems (IPS) have long been a part of the enterprise security defense in depth matrix, and part of a DLP strategy involves keeping unauthorized persons out of the local network. However, DLP is actually more focused on the prevention of extrusion, that is, data going out of the network, and so while IDS/IPS is aimed primarily at filtering inbound traffic, DLP aims at filtering outbound traffic. The goal of DLP is to prevent anything from leaving the network that could, in the wrong hands, be detrimental to the organization.

Extrusion prevention isn’t easy in today’s network environment that encompasses Bring Your Own Device (BYOD), easy peer-to-peer file sharing, free web mail, IM/chat programs that support file sharing, a proliferation of readily available and easy to use cloud-based storage services and other means of transferring files across the Internet, along with cheap and almost universally compatible physical storage devices that can be easily plugged in via USB, writable optical drives, tiny and easy to conceal/smuggle out flash memory cards, and so forth.

Data classification

An important part of an effective DLP strategy includes the classification of data to allow you to accurately identify the sensitivity level of data and the impact of loss or disclosure of each data set. The FIPS-199 federal government publication can serve as a guideline for the development of a data classification scheme. This document bases the impact classifications on the three FISMA (Federal Information Security Management Act) security objectives: confidentiality, integrity and availability. Thus potential impact from a security breach could result in:

  • Unauthorized disclosure of information (loss of confidentiality)
  • Unauthorized change or destruction of information (loss of integrity)
  • Disruption of access or use of information (loss of availability

After you have determined a classification for each piece of data, you can use tagging to embed that classification into the metadata and tools can be used to enforce security measures that are based on the data classification.


A data loss and data leakage prevention strategy is a must for any organization that creates, uses, stores, moves or accesses any type of data that is sensitive, confidential or falls under regulatory privacy protection mandates. In Part 1 of this article, we’ve provided a high level overview of what DLP is, some of the possible consequences of data loss or leakage, and the essential elements of an effective DLP strategy. In subsequent installments, we will delve more deeply into the intricacies of DLP, characteristics of good DLP software solutions, and how to implement your DLP plan.



20 مهر 1394 برچسب‌ها: مقالات
Assessing the Security of Mobile applications (Part 2) - Testing the application (section 2)

Number: IRCAR201508270

Date: 2015-08-26

Testing per requirement

The requirements should be tested to achieve an outcome of either violation of the requirement, or the requirement has been met and is satisfactory.

These results will assist in concluding whether the app should be approved or rejected at a later stage depending on the organisations specific requirements and the organisations risk acceptance levels.

Requirement being tested

What to consider with regards to the app

Enabling authorised functionality

Test the user interface (displays, virtual keyboards, buttons)

Test all physical attributes used by the app (cameras, GPS, microphones, communication between devices)

Make sure calls and messages are not being utilised for purposes of the app functionality

Ensure all these attributes are functioning as intended

Preventing unauthorised functionality

Look out for intentional malicious functioning violating security (functions that assist fraudulent activity, stealing of information, opening doors for attack)

Banner ads are sometimes utilised to deceive users and provision phishing attacks

Malware detection is important but not 100% guaranteed effective

Ensure that the app doesn’t converse with untrustworthy sites, domains or servers

Limiting permissions

Ensure that the app does not have excessive permissions but the least permissions required for its intended functioning

The more permissions it has the less secure it is and the higher the potential security risk

Look out for the following permissions and consider carefully whether any are necessary:

  • Access to and storage of sensitive data (address book, contacts, passwords etc.)
  • Access to camera
  • Access to microphone
  • File input/output and removable storage (access to files)
  • Privileged commands (ability to activate commands allowing unauthorised system access and elevated attacks)
  • APIs should be carefully considered and only the required permitted

Protecting sensitive data

Apps most likely process sensitive data in one form or another, this should only be allowed if the appropriate cryptographic procedures are used to ensure the data remains secure and private

Validated cryptography must be used and implemented correctly as well as suitable key management utilised

Digital certificates need to always be properly validated

Data leakage via various unauthorised network routes needs to be considered (cellular, Wi-Fi, Bluetooth, shared system logs)

It’s recommended to study the app logs to distinguish the type of data that is leaked

Securing app code dependencies

Make sure the app does not use unsafe code. Care should be taken to only depend on code from an external source when really necessary

(Consider: external libraries and classes, dynamic behaviour, native calls and apps that communicate with each other)

Although these behaviours can prove beneficial they can also pose a great security risk so their functioning should be carefully considered and only allowed if undertaken securely.

Testing app updates

Updates should always be tested to avoid new vulnerabilities or the introduction of new weaknesses. This should be done before the update is downloaded to the mobile device.

Mobile device management within the organisation plays an important part with regards to test updates. Some polices will allow for unprompted updates, when made available, this approach should be avoided whenever possible.

Updates should always require pre-authorisation and should not be allowed to be automatic so that vetting of the update can be undertaken prior to installation.

Table 1

Test Methods

A varied set of test methods can be used for application vetting. Below are a few that we will cover in more detail in the article to follow (Part three)

Test methods could include:

  • Correctness testing
  • Source or binary code analysis
  • Static or dynamic analysis
  • Manual testing
  • Automated testing


It is critical to test an applications security features and stability to ensure secure mobile computing for both your user base and the organisations. At the high speed that apps are released some security gaps are missed and thus the exposure factor and risk is higher.

A key strategy is to build security into the development lifecycle with rigorous and methodical testing to ensure that the application is properly built. Independent vulnerability assessments and application penetration testing is highly recommended before releasing both internal and external applications.



20 مهر 1394 برچسب‌ها: مقالات
Developing and Assessing your DLP Strategy (Part 1)-section 1

Number: IRCAR201508269

Date: 2015-08-21


As IT security professionals, we spend a great deal of time worrying about how to secure the infrastructure, operating system and applications, but when it comes right down to it, in the end it’s all about the data. An OS or app can be reinstalled and will be good as new – albeit with administrative overhead and possible temporary loss of productivity – but lost data may be irreplaceable and in some cases its loss or exposure can have severe ramifications for your business.

That’s why DLP (Data Loss Prevention or Data Loss Protection, depending on the source) has turned into a whole security subset of its own. Of course, DLP ties into other security areas such as regulatory compliance and protection of trade secrets. In this multi-part article, we will discuss how your organization can develop an effective DLP strategy and/or how to assess your existing policy for holes that might need to be plugged.

The challenge of developing an effective DLP policy

Developing an effective DLP policy with broad coverage is especially challenging because data comes in so many different forms: word processing documents, spreadsheets, email communications, database entries, XML files, chat logs, proprietary formats created by custom line of business applications, and even graphics files. Then there are multiple methods by which that data can be lost, including but not limited to the following:

  • Hack attacks from outside the local network
  • Physical access to the local network by outsiders through social networking
  • Deliberate insider data theft (corporate espionage, disgruntled employees, contractors, etc.)
  • “Hacking the cloud” (if you store your data there)
  • Interception of data in transit between one network and another or one endpoint and another
  • Physical loss or theft of mobile devices
  • Accidental leakage from inside the local network by authorized persons

All of these variables make it particularly important that your DLP strategy be multi-layered and that it be reassessed frequently to insure that methods of loss haven’t been overlooked or new ones introduced by changes to your network infrastructure and configuration (for example, a move to the cloud). Effective DLP is unlikely to be accomplished by a single turn-key solution, but will require a combination of security mechanisms to protect data in various locations and at various stages of creation, use, transit and storage.

DLLP: data loss and leakage

In fact, the most comprehensive strategy might be more accurately referred to as DLLP, or Data Loss and Leakage Prevention. Many IT professionals lump data loss and data leakage into the same basket, and they are related but there is a key difference. Data loss is what it sounds like: the data is either destroyed or taken away and you no longer have access to it. Data leakage is more insidious (and thus it can be more difficult to detect): the data is exposed or disclosed to persons who are not authorized to have access to it, but it is still left intact in its original location.

Thieves who only want to utilize the information in the data (for example, to use personal credit card information of your customers for identity theft or use information regarding your company’s trade secrets to sell to your competitors) would typically steal copies of the data and leave the originals alone so that you would not immediately be alerted to the fact that there had been a breach.

On the other hand, attackers who want to disrupt your business and cause you lost productivity in order to allow the competition to get ahead, or who want to get back at you over some grievance (such as a dissatisfied customer or a disgruntled employee or ex-employee) would more typically tend to destroy the data completely or copy it for themselves and then remove the original files from their location.

However, the common terminology is DLP and so, for the purposes of this document, we will use that verbiage to refer to both data loss prevention and data leakage prevention.



20 مهر 1394 برچسب‌ها: مقالات
Assessing the Security of Mobile applications (Part 2) - Testing the application (section 1)

Number: IRCAR201508267

Date: 2015-08-11


To support BYOD and to take advantage of the multiple applications available to organisations it’s essential that the applications be properly vetted before installation and use so that any vulnerability can be uncovered and organisations can improve business function with minimal risk. It’s very important that applications are secure and function as intended.

To recap we concluded that the app assessing process should include:

  • Planning (covered in article one)
  • Testing of applications (covered in this article and the third article of this series)
  • Application approval or rejection (to be covered in the third article of this series)

In the first article of this series we looked at planning, the initial steps in the application vetting process.

In this article we will cover testing of applications. As part of the planning process, responsibilities would have been assigned and a team positioned to facilitate the application testing process (this covered in part 1).

Processes for testing should be consistent and easily repeatable as well as efficient so that room for error and false negatives and positives are minimized.

Analysis will involve first establishing whether the application will be suited to the testing procedures to be undertaken (pre-processing), followed by testing the app for vulnerabilities using various methods.

All discovered issues and recommendations should be reported and a risk assessment initiated to validate the next steps in the vetting procedure.

A few things to take into consideration:

  • Provision a procedure whereby the security of the app can be assessed
  • Testing should be undertaken after app development but before the app is deployed on the mobile device
  • Don’t forget to test the application updates- this is very important
  • Use a secure approach when testing (utilise encryption where possible for transfer and storage)
  • The strategy should be aligned with your organisations unique security requirements, this should be carefully considered as it is necessary to specify the organisations security requirements to use as a baseline for the vetting process
  • Ensure that any previous testing is not taken as final, as one organisation's security requirement or risk acceptance level may be very different from that of another
  • The app testing can be done internally or externally by service, tool or hands-on manual testing or a combination of various techniques

Testing the application


The delegated team or individual will arrange that the application be forwarded for testing. The application will be sent to the analyser/s, which may be in-house or external to the organisation for analysis.

The initial steps in the testing of the app are for pre-processing whereby the app will be analysed to confirm its suitability to the testing methods, this often involves de-compilation of the app and storage of the app file. This may be cause for concern with regards to the security of the app/files/code, especially if the analyser is not part of the organisation but rather a third party.

Precautionary measures need to be taken to ensure that the apps security and integrity is not compromised during the pre-processing stage. Organisations must ensure that the app compliance with license agreements remains intact during processing and intellectual property protected. Transferring the app via an encrypted channel and ensuring it is stored securely and that appropriate measures are taken to prevent unauthorised access will help safeguard that the security of the app is upheld at all times and throughout the testing procedures.

Testing the app for software weaknesses

Before vulnerabilities can be uncovered a set of security requirements need to be stipulated for the app. These requirements laid out are used as a baseline to ascertain whether the vulnerability found will violate the requirements or not by testing appropriately with that particular requirement in mind. The requirement signifies a feature or conduct that the app should display to ensure that it’s secure. The requirements are also valuable for when security audits are undertaken.

The recommended security requirements should look as follows:

  • Enabling authorised functionality
  • Preventing unauthorised functionality
  • Limiting permissions (apps should function with the least required permissions and allow the same (least) to other apps)
  • Protecting sensitive data
  • Securing app code dependencies (ensure code dependencies are used sensibly and not for malicious activity)
  • Testing app updates (updates for apps must always be tested as if it were a new app, prior to installation on the mobile device.)



20 مهر 1394 برچسب‌ها: مقالات
DCL02-J. Do not modify the collection's elements during an enhanced for statement

ID: IRCAR201507266

Date: 2015-07-22
The enhanced for statement is designed for iteration through Collections and arrays.
The Java Language Specification (JLS) provides the following example of the enhanced for statement in §14.14.2, "The Enhanced for Statement" [JLS 2014]:
Unlike the basic for statement, assignments to the loop variable fail to affect the loop's iteration order over the underlying set of objects. Consequently, an assignment to the loop variable is equivalent to modifying a variable local to the loop body whose initial value is the object referenced by the loop iterator. This modification is not necessarily erroneous but can obscure the loop functionality or indicate a misunderstanding of the underlying implementation of the enhanced for statement.
Declare all enhanced for statement loop variables final. The final declaration causes Java compilers to flag and reject any assignments made to the loop variable.
Noncompliant Code Example
This noncompliant code example attempts to process a collection of integers using an enhanced for loop. It further intends to modify one item in the collection for processing:
However, this code does not actually modify the list, as shown by the program's output:
Compliant Solution
Declaring i to be final mitigates this problem by causing the compiler to fail to permit i to be assigned a new value:
Compliant Solution
This compliant solution processes the "modified" list but leaves the actual list unchanged:
Risk Assessment
Assignments to the loop variable of an enhanced for loop (for-each idiom) fail to affect the overall iteration order, lead to programmer confusion, and can leave data in a fragile or inconsistent state.
Automated Detection
This rule is easily enforced with static analysis.

6 مرداد 1394 برچسب‌ها: مقالات
صفحات: 1 2 3 4 5 ... » »»