فا

‫ اخبار

صفحات: «« « ... 3 4 5 6 7 ... » »»
Small Office/Home Office Router Security – Part 1
IRCAR201404208

Date: 2014-04-08

Introduction

Home routers have become an integral part of our modern society as our use of the internet has grown to include business from home, schoolwork, social networking, entertainment and personal financial management. Wired and now wireless routers have moved into our homes to facilitate this additional connectivity. The internet service provider (ISP) sells these devices pre­ configured and ready to use. Users typically connect immediately to the internet without performing any additional configuration.

Unfortunately, the default configuration of most home routers offer little security and leave home networks vulnerable to attack. Small businesses and organizations that lack the funding for an information technology (IT) infrastructure and support staff often use these same home routers to connect to the internet. These organizations frequently also set up the routers without implementing security precautions.

Security Concerns

The default configurations of most home routers offer little security. Home routers are directly accessible from the internet, are easily discoverable, are usually powered-on at all times, and in many cases are vulnerable due to misconfiguration. These characteristics offer an intruder the perfect attack vector. The wireless features incorporated into many of these devices adds another vulnerable attack vector.

Mitigation

The mitigation steps listed below are designed to increase the security of home routers and reduce the vulnerability of the internal network against attacks from external sources.

Change the default login username and password: Manufacturers set default usernames and passwords for these devices at the factory to provide users access to configure the device. These default usernames and passwords are readily available in different publications and are well known to attackers; therefore, they should be immediately changed during the initial router installation. A strong password that uses a combination of letters and numbers with 14 characters or more is recommended. Furthermore, change passwords every 30 to 90 days.

Change the default SSID: A service set identifier (SSID) is a unique name that identifies a particular wireless LAN (WLAN). All wireless devices on a WLAN must use the same SSID in order to communicate with each other. Manufacturers set a default SSID at the factory that typically identifies the manufacturer or the actual device. An attacker can use the default name to identify the device and any vulnerability associated with it. Users sometimes set the SSID to a name that identifies their organization, their location, their own name, etc. This makes it easier for the attacker to identify their specific business or home network based upon an SSID easily identified with their name. For example, an SSID that broadcasts a company name is a more attractive target then a router broadcasting “ABC123”. When choosing an SSID, follow the best practices policy for password complexity as described below:

o The minimum length of an SSID should be greater than eight characters long.

o Use alphanumeric and symbols in the SSID.

o Change the SSID on a reoccurring basis and discourage the use of previous passwords.

Configure WPA2-AES for data confidentiality: Wireless Equivalent Privacy (WEP) is a security algorithm intended to provide data confidentiality (authentication and encryption) but has serious weaknesses. WEP was superseded by the 802.11 standard implemented as Wi-Fi Protected Access (WPA), which has a newer version, WPA2. WPA and WPA2 provide stronger authentication and encryption using dynamically changing keys. WPA and WPA2 come in personal and enterprise versions. WPA- Personal, also referred to WPA-PSK (Pre-Shared Key), was designed for homes and small offices using pre-shared keys without requiring an authentication server. If using WPA-PSK, set a long pre-shared key and change it periodically. WPA-Enterprise requires a RADIUS authentication server, uses Extensible Authentication Protocol (EAP), and provides added security, but it entails a larger budget and more complicated implementation. WPA2 incorporates AES 128-bit encryption accepted by government agencies. WPA2 with AES represents the most secure option, and all wireless devices must be WPA2 compliant. If WPA2 is not feasible, WPA is an alternative. WEP represents the least secure option. If used, WEP should be configured with the 128-bit key option with the longest pre-shared key the router administrator can manage.

Limit WLAN coverage: LANs are inherently more secure than WLANs because they are protected by the physical structure in which they reside. WLAN coverage frequently extends beyond the perimeters of your home or organization. This allows eavesdropping by intruders outside your network perimeter. Therefore, antenna placement, antenna type, and transmission power levels are important aspects to consider. Limit the broadcast coverage area when securing your WLAN. A centrally located omni-directional antenna is the most common type used. If possible, use a directional antenna to direct WLAN coverage to only the areas needed. Experimenting with transmission levels and signal strength will also limit the coverage to only the areas needed.

Turn the network off when not in use: The ultimate in wireless security measures, shutting down the network, will most certainly prevent outside attackers from breaking in. While it may be impractical to turn the devices off and on frequently, consider this approach during travel or extended periods offline.

In part 2, we’ll look at the other mitigation steps to increase the security of home routers.


Resource:

www.US-cert.gov

18 مرداد 1393 برچسب‌ها: مقالات
Java Secure Coding - Input Validation and Data Sanitization Rules – IDS06-J
IRCAR201404209
Number: IRCAR201404209

Date: 2014-04-13

IDS06-J. Exclude unsanitized user input from format strings

Interpretation of Java format strings is stricter than in languages such as C [Seacord 2013]. The standard library implementations throw appropriate exceptions when any conversion argument fails to match the corresponding format specifier. This approach reduces opportunities for malicious exploits. Nevertheless, if malicious user input is accepted in a format string, it can cause information leaks or denial of service. As a result, input from an untrusted source should not be incorporated into format strings.
Noncompliant Code Example

This noncompliant code example demonstrates an information leak issue. It accepts a credit card expiration date as an input argument and uses it within the format string.

classFormat {

staticCalendar c =

newGregorianCalendar(1995, GregorianCalendar.MAY, 23);

publicstaticvoidmain(String[] args) {

// args[0] is the credit card expiration date

// args[0] can contain either %1$tm, %1$te or %1$tY as malicious

// arguments

// First argument prints 05 (May), second prints 23 (day)

// and third prints 1995 (year)

// Perform comparison with c, if it doesn't match print the

// following line

System.out.printf(args[0] +

" did not match! HINT: It was issued on %1$terd of some month", c);

}
}

In the absence of proper input validation, an attacker can determine the date against which the input is being verified by supplying an input that includes one of the format string arguments %1$tm, %1$te, or %1$tY.


Compliant Solution

This compliant solution ensures that user-generated input is excluded from format strings.

classFormat {

staticCalendar c =

newGregorianCalendar(1995, GregorianCalendar.MAY, 23);

publicstaticvoidmain(String[] args) {

// args[0] is the credit card expiration date

// Perform comparison with c,

// if it doesn't match, print the following line

System.out.printf("%s did not match! "

+ " HINT: It was issued on %1$terd of some month", args[0],c);

}
}
Risk Assessment

References:

https://www.securecoding.cert.org/confluence/display/java/The+CERT+Oracle+Secure+Coding+Standard+for+Java

18 مرداد 1393 برچسب‌ها: مقالات
DDoS Quick Guide - Part 1
IRCAR201404207
Date: 2014-04-01

The core concepts of cyber security are availability, integrity, and confidentiality. Denial of Service (DoS) attacks impact the availability of information resources. The DoS is successful if it renders information resources unavailable. Success and impact differ in that impact is relative to the victim.

Possible DDoS Traffic Types

HTTP Header

HTTP headers are fields which describe which resources are requested, such as URL, a form, JPEG, etc. HTTP headers also inform the web server what kind of web browser is being used. Common HTTP headers are GET, POST, ACCEPT, LANGUAGE, and USER AGENT. The requester can insert as many headers as they want and can make them communication specific. DDoS attackers can change these and many other HTTP headers to make it more difficult to identify the attack origin. In addition, HTTP headers can be designed to manipulate caching and proxy services. For example, is it possible to ask a caching proxy to not cache the information.

HTTP POST Flood

An HTTP POST Flood is a type of DDoS attack in which the volume of POST requests overwhelms the server so that the server cannot respond to them all. This can result in exceptionally high utilization of system resources and consequently crash the server.

HTTP POST Request

An HTTP POST Request is a method that submits data in the body of the request to be processes by the server. For example, a POST request takes the information in a form and encodes it, then post the content of the form to the server.

HTTPS POST Flood

An HTTPS POST Flood is an HTTP POST flood sent over an SSL session. Due to the use of SSL it is necessary to decrypt this request in order to inspect it.

HTTPS POST Request

An HTTPS POST Request is an encrypted version of an HTTP POST request. The actual data transferred back and forth is encrypted.

HTTPS GET Flood

An HTTPS GET Flood is an HTTP GET flood sent over an SSL session. Due to the SSL, it is necessary to decrypt the requests in order to mitigate the flood.

HTTPS GET Request

An HTTPS GET Request is an HTTP GET Request sent over an SSL session. Due to the use of SSL, it is necessary to decrypt the requests in order to inspect it.

HTTP GET Flood

An HTTP GET Flood is a layer 7 application layer DDoS attack method in which attackers send a huge flood of requests to the server to overwhelm its resources. As a result, the server cannot respond to legitimate requests from the server.

HTTP GET Request

An HTTP GET Request is a method that makes a request for information for the server. A GET request asks the server to give you something such as an image or script so that it may be rendered by your browsers.

SYN Flood (TCP/SYN)

SYN Flood works by establishing half-open connections to a node. When the target receives a SYN packet to an open port, the target will respond with a SYN-ACK and try to establish a connection. However, during a SYN flood, the three-way handshake never completes because the client never responds to the server's SYN-ACK. As a result, these "connections" remain in the half-open state until they time out.

UDP Flood

UDP floods are used frequently for larger bandwidth DDoS attacks because they are connectionless and it is easy to generate protocol 17 (UDP) messages from many different scripting and compiled languages.

ICMP Flood

Internet Control Message Protocol (ICMP) is primarily used for error messaging and typically does not exchange data between systems. ICMP packets may accompany TCP packets when connecting to a sever. An ICMP flood is a layer 3 infrastructure DDoS attack method that uses ICMP messages to overload the targeted network's bandwidth.

MAC Flood

A rare attack, in which the attacker sends multiple dummy Ethernet frames, each with a different MAC address, Network switches treat MAC addresses separately, and hence reserve some resources for each request. When all the memory in a switch is used up, it either shuts down or becomes unresponsive. In a few types of routers, a MAC flood attack may cause these to drop their entire routing table, thus disrupting the whole network under its routing domain.

SomeDDoSMitigationActionsandHardware

· Statefulinspectionfirewalls

· Stateful SYN Proxy Mechanisms

· Limiting the number of SYNs per second per IP

· Limiting the number of SYNs per second per destination IP

· Set ICMP flood SCREEN settings (thresholds) in the firewall

· Set UDP flood SCREEN settings (thresholds) in the firewall

· Rate limit routersadjacent to thefirewalland network

Resource:

http://www.us-cert.gov/

18 مرداد 1393 برچسب‌ها: مقالات
DDoS Quick Guide - Part 1
IRCAR201404207


Date: 2014-04-01

Thecoreconceptsofcybersecurityareavailability,integrity,andconfidentiality.DenialofService(DoS)attacksimpacttheavailability ofinformationresources.TheDoSissuccessfulifitrendersinformationresourcesunavailable.Successandimpactdifferinthatimpact isrelativetothevictim.

PossibleDDoSTrafficTypes

HTTP Header

HTTP headers are fields which describe which resources are requested, such as URL, a form, JPEG, etc. HTTP headers also inform the web server what kind of web browser is being used. Common HTTP headers are GET, POST, ACCEPT, LANGUAGE, and USER AGENT. The requester can insert as many headers as they want and can make them communication specific. DDoS attackers can change these and many other HTTP headers to make it more difficult to identify the attack origin. In addition, HTTP headers can be designed to manipulate caching and proxy services. For example, is it possible to ask a caching proxy to not cache the information.

HTTP POST Flood

An HTTP POST Flood is a type of DDoS attack in which the volume of POST requests overwhelms the server so that the server cannot respond to them all. This can result in exceptionally high utilization of system resources and consequently crash the server.

HTTP POST Request

An HTTP POST Request is a method that submits data in the body of the request to be processes by the server. For example, a POST request takes the information in a form and encodes it, then post the content of the form to the server.

HTTPS POST Flood

An HTTPS POST Flood is an HTTP POST flood sent over an SSL session. Due to the use of SSL it is necessary to decrypt this request in order to inspect it.

HTTPS POST Request

An HTTPS POST Request is an encrypted version of an HTTP POST request. The actual data transferred back and forth is encrypted.

HTTPS GET Flood

An HTTPS GET Flood is an HTTP GET flood sent over an SSL session. Due to the SSL, it is necessary to decrypt the requests in order to mitigate the flood.

HTTPS GET Request

An HTTPS GET Request is an HTTP GET Request sent over an SSL session. Due to the use of SSL, it is necessary to decrypt the requests in order to inspect it.

HTTP GET Flood

An HTTP GET Flood is a layer 7 application layer DDoS attack method in which attackers send a huge flood of requests to the server to overwhelm its resources. As a result, the server cannot respond to legitimate requests from the server.

HTTP GET Request

An HTTP GET Request is a method that makes a request for information for the server. A GET request asks the server to give you something such as an image or script so that it may be rendered by your browsers.

SYN Flood (TCP/SYN)

SYN Flood works by establishing half-open connections to a node. When the target receives a SYN packet to an open port, the target will respond with a SYN-ACK and try to establish a connection. However, during a SYN flood, the three-way handshake never completes because the client never responds to the server's SYN-ACK. As a result, these "connections" remain in the half-open state until they time out.

UDP Flood

UDP floods are used frequently for larger bandwidth DDoS attacks because they are connectionless and it is easy to generate protocol 17 (UDP) messages from many different scripting and compiled languages.

ICMP Flood

Internet Control Message Protocol (ICMP) is primarily used for error messaging and typically does not exchange data between systems. ICMP packets may accompany TCP packets when connecting to a sever. An ICMP flood is a layer 3 infrastructure DDoS attack method that uses ICMP messages to overload the targeted network's bandwidth.

MAC Flood

A rare attack, in which the attacker sends multiple dummy Ethernet frames, each with a different MAC address, Network switches treat MAC addresses separately, and hence reserve some resources for each request. When all the memory in a switch is used up, it either shuts down or becomes unresponsive. In a few types of routers, a MAC flood attack may cause these to drop their entire routing table, thus disrupting the whole network under its routing domain.

SomeDDoSMitigationActionsandHardware

· Statefulinspectionfirewalls

· Stateful SYN Proxy Mechanisms

· Limiting the number of SYNs per second per IP

· Limiting the number of SYNs per second per destination IP

· Set ICMP flood SCREEN settings (thresholds) in the firewall

· Set UDP flood SCREEN settings (thresholds) in the firewall

· Rate limit routersadjacent to thefirewalland network

18 مرداد 1393 برچسب‌ها: مقالات
Java Secure Coding - Input Validation and Data Sanitization Rules – IDS05-J
IRCAR201403206
Date: 2014-03-19

File and path names containing particular characters can be troublesome and can cause unexpected behavior resulting in vulnerabilities. The following characters and patterns can be problematic when used in the construction of a file or path name:

· Leading dashes: Leading dashes can cause problems when programs are called with the file name as a parameter because the first character or characters of the file name might be interpreted as an option switch.

· Control characters, such as newlines, carriage returns, and escape: Control characters in a file name can cause unexpected results from shell scripts and in logging.

· Spaces: Spaces can cause problems with scripts and when double quotes are not used to surround the file name.

· Invalid character encodings: Character encodings can make it difficult to perform proper validation of file and path names. (See IDS11-J. Eliminate noncharacter code points before validation).

· Name-space separation characters: Including name-space separation characters in a file or path name can cause unexpected and potentially insecure behavior.

· Command interpreters, scripts, and parsers: Some characters have special meaning when processed by a command interpreter, shell, or parser and should consequently be avoided.

As a result of the influence of MS-DOS, file names of the form xxxxxxxx.xxx, where x denotes an alphanumeric character, are generally supported by modern systems. On some platforms, file names are case sensitive, and on other platforms, they are case insensitive. VU#439395 is an example of a vulnerability in C resulting from a failure to deal appropriately with case sensitivity issues [VU#439395].

This is a specific instance of IDS00-J. Sanitize untrusted data passed across a trust boundary.

Noncompliant Code Example

In the following noncompliant code example, unsafe characters are used as part of a file name.

File f = newFile("A\uD8AB");

OutputStream out = newFileOutputStream(f);

A platform is free to define its own mapping of the unsafe characters. For example, when tested on an Ubuntu Linux distribution, this noncompliant code example resulted in the following file name:

A?
Compliant Solution

Use a descriptive file name, containing only the subset of ASCII previously described.

File f = newFile("name.ext");

OutputStream out = newFileOutputStream(f);

Noncompliant Code Example

This noncompliant code example creates a file with input from the user without sanitizing the input.

publicstaticvoidmain(String[] args) throwsException {

if(args.length < 1) {

// Handle error

}

File f = newFile(args[0]);

OutputStream out = newFileOutputStream(f);

// ...
}

No checks are performed on the file name to prevent troublesome characters. If an attacker knew this code was in a program used to create or rename files that would later be used in a script or automated process of some sort, the attacker could choose particular characters in the output file name to confuse the later process for malicious purposes.

Compliant Solution

In this compliant solution, the program uses a whitelist to reject unsafe file names.

publicstaticvoidmain(String[] args) throwsException {

if(args.length < 1) {

// Handle error

}

String filename = args[0];

Pattern pattern =

Pattern.compile("[^A-Za-z0-9%&+,.:=_]");

Matcher matcher = pattern.matcher(filename);

if(matcher.find()) {

// File name contains bad chars; handle error

}

File f = newFile(filename);

OutputStream out = newFileOutputStream(f);

// ...
}

All file names originating from untrusted sources must be sanitized to ensure they contain only safe characters.

Risk Assessment

References:

https://www.securecoding.cert.org/confluence/display/java/IDS05-J.+Use+a+subset+of+ASCII+for+file+and+path+names
18 مرداد 1393 برچسب‌ها: مقالات
Network Access Control
IRCAR201403204
Date: 2014/03/11

The history of NAC

Network Access Control (NAC) has been around for some time, nearly a decade, evaluating devices connecting to networks, and restricting the availability of the network resources to only the devices that comply with clearly defined security policies.

Mobile devices are on the increase and more companies moving toward BYOD strategies, organizations now require solutions that are balanced, contextual, mature and scalable, and one that takes security and compliance into account and is capable of handling the dynamic environment in today’s diverse businesses.

It makes sense to allow users to have secure access to the network resources to perform their roles, both on site and remotely, whilst critical business systems and processes remain secure and isolated from exploitation and compromise. NAC usage is definitely on the increase, it had a slow start when entering the market in 2004.

Today’s diverse environments demand dynamic balanced yet secure Network Access Control. Organisations want the benefits provided by NAC at a network level, but also require additional contextual security strategies such a Mobile Device Management (MDM) at a device level. A combined security solution of the traditional NAC capabilities complimented by the capabilities of mobile security, endpoint compliance and threat management is necessary for a secure mobile age. This will ensure a defence in-depth approach, but the final barrier is still the culture, and the user’s acceptance of such an approach.

Key Functions of a NAC solution
  • Performs authentication and authorisation, pre the access to the protected environment.
  • Protection, organisations are guarded against security threats as well as attacks from viruses and worms through anti-threat measures ( firewalls, antivirus solutions and spyware) compliance and comparison to the security benchmark is possible before allowing access to the guarded environment.
  • Prevents adverse usage of network resources.
  • Enforces communication policies and regulates and restricts the tasks users can undertake once connected to the network allowing for efficient business process.
  • Ensures a security layer between systems that have been away from the network for a period of time, whilst checking for security posture to ensure systems comply with common and current security baseline.
Important aspects to achieving an effective NAC solution
  • The NAC solution must be deployable in an open architecture that is adaptable to the organisations requirements.
  • The solution must be able to support multiple device types running multiple types of operating systems as the environments of today are diverse. A solution that is only suited to certain end systems leaves the network and services vulnerable to attack from systems not included in the security posture.
  • The NAC solution must be flexible enough to all for integration of multiple assessment technology types. By doing this the NAC solution is able to cover any endpoint device, mobile or system connecting to the network.
  • Devices should be assessed before connection is allowed as well as post connection.
  • The NAC solution must be able to address end devices/systems connected to varying types of network switches.
  • All access must be logged.
  • The NAC solution should adhere to standards-based authentication and policy enforcement technologies.
  • Ensure that the NAC solution includes all end devices/systems. With the consciousness of converged networks in business today, networks are coming into contact with a range of devices/systems from the desktops, laptops and printers through to the growing mobile devices (Tablets and phones) to name a few.
  • Should not have security specific to certain device types, operating systems or software. Security should be focusing on covering the wide range of end systems out there-the list is endless.
  • The solution should be capable of assessing authenticating and authorising varying end devices using varying operating systems and running differing applications.
  • The NAC solution should consider a multiple of attributes before allowing a device access to the network. These attributes should include, over and above the authorisation of the device, device type, location, time, user credentials, machine credentials, and the function of the device within business. Through proper assessment effective access or redirection can be applied. The more information gained during authorisation will lead to a more effective and secure solution.
  • Accurate policy enforcement is a significant facet of the NAC solution. Through enforcing policies at the network connection point of the device you can ensure that the network usage is secure, efficient and being utilised as it should. Policies should be such that they can be enforced throughout the network to achieve ultimate control. Policies should include those for devices as well as network usage.
  • Include a policy to quarantine devices that are not meant to connect to the network until such time that the device complies with network policy. By doing this the entire network is not placed at risk or compromised. The user should be notified (web browser, instant messaging or email) that their device has been quarantined and given the appropriate information required to rectify the issue.
  • Compliance reporting is essential for a well-run NAC solution. The network access control solution should be able to collect information on devices, users and communications. This data can be utilised for compliance reporting for both historical and real time events.
Network Access Control for mobile devices

Excessive growth in the use of mobile devices in business has led to the acknowledgment that greater visibility and extensive network based control is required for solving endpoint concerns. To achieve this, the NAC solution should not be based purely on device authentication as per its initial function but rather altered such that it offers more flexibility over the control of the network.

A combination of NAC, Mobile Device Management (MDM) and Mobile Application Management (MAM) can provide a substantial business framework for securing the network and enabling secure remote working via mobile devices. By using a combination of these solutions the NAC can be adjusted for access of mobile devices while still receiving effective security measures and adhering to regulatory requirements.

Through NAC solutions interfacing directly with other security strategies, compliance reports produced show a complete and accurate image of end systems/devices connected to the network.

Capabilities of a combined NAC/MDM/MAM solution
  • Automatic identification and control of devices connecting to the network.
  • All types of devices or end systems can be identified
  • Detection of jail broken or rooted devices
  • Continuous device monitoring on the network
  • Detection of malware, spyware and viruses
  • Compliance: real time monitoring
  • Full audit trail of access to the resources
  • Baseline comparison and security posture assessment.
  • Easier implementation of the solution. Virtual or cloud solution are available
  • A more mature and flexible solution
Conclusion

Network Access Control is an essential element to a complete network security design to protect the privacy, integrity and accessibility of business information assets. It also has an important role in network assessment, authorisation, policy enforcement, security posture assessment and remediation.

The combined NAC and MDM solution offers best of both worlds, ensuring a balanced secure network as well as a secure managed device or endpoint.

The downside to the solution being the cost, if implemented correctly the solution is not an economical one, however organisations need to way up the cost against the benefits, as mobile devices and remote working are here to stay.

References:

http://www.windowsecurity.com/articles-tutorials/authentication_and_encryption/hardening-core-part2.html

18 مرداد 1393 برچسب‌ها: مقالات
Java Secure Coding - Input Validation and Data Sanitization Rules – IDS04-J
IRCAR201402203
IDS03-J. Safely extract files from ZipInputStream
Be careful when extracting entries from java.util.zip.ZipInputStream. Two particular issues to avoid are entry file names that canonicalize to a path outside of the target directory of the extraction and entries that cause consumption of excessive system resources. In the former case, an attacker can write arbitrary data from the zip file into any directories accessible to the user. In the latter case, denial of service can occur when resource usage is disproportionately large in comparison to the input data that causes the resource usage. The nature of the zip algorithm permits the existence of zip bombs in which a small file, such as ZIPs, GIFs, and gzip-encoded HTTP content, consumes excessive resources when uncompressed because of extreme compression.
The zip algorithm can produce very large compression ratios. For example, a file consisting of alternating lines of a characters and b characters can achieve a compression ratio of more than 200 to 1. Even higher compression ratios can be easily obtained using input data that is targeted to the compression algorithm, or using more input data (that is untargeted), or using other compression methods.
Any entry targeting a file not within the directory intended by the client program (after file name canonicalization, as per IDS02-J. Canonicalize path names before validating them), must not be extracted or must be extracted to a safe location. Any entry in a zip file whose uncompressed file size is beyond a certain limit must not be uncompressed. The actual limit is dependent on the capabilities of the platform.
Noncompliant Code Example
This noncompliant code fails to validate the name of the file that is being unzipped. It passes the name directly to the constructor of FileOutputStream. It also fails to check the resource consumption of the file that is being unzipped. It permits the operation to run to completion or until local resources are exhausted.
Compliant Solution (Security Manager)
This compliant solution just validates the username input before logging it, preventing injection attacks. Refer to IDS00-J. Sanitize untrusted data passed across a trust boundary for more details on input sanitization.
staticfinalintBUFFER = 512;
// ...
publicfinalvoidunzip(String filename) throwsjava.io.IOException{
FileInputStream fis = newFileInputStream(filename);
ZipInputStream zis = newZipInputStream(newBufferedInputStream(fis));
ZipEntry entry;
try{
while((entry = zis.getNextEntry()) != null) {
System.out.println("Extracting: "+ entry);
intcount;
bytedata[] = newbyte[BUFFER];
// Write the files to the disk
FileOutputStream fos = newFileOutputStream(entry.getName());
BufferedOutputStream dest = newBufferedOutputStream(fos, BUFFER);
while((count = zis.read(data, 0, BUFFER)) != -1) {
dest.write(data, 0, count);
}
dest.flush();
dest.close();
zis.closeEntry();
}
} finally{
zis.close();
}
}
Compliant Solution
In this compliant solution, the code validates the name of each entry before extracting the entry. If the name is invalid, the entire extraction is aborted. However, a compliant solution could also skip only that entry and continue the extraction process, or it could even extract the entry to some safe location.
Furthermore, the code inside the while loop tracks the uncompressed file size of each entry in a zip archive while extracting the entry. It throws an exception if the entry being extracted is too large—about 100MB in this case. We do not use the ZipEntry.getSize() method because the value it reports is not reliable. Finally, the code also counts the number of file entries in the archive, and throws an exception if there are more than 1024 entries.
Risk Assessment
References:
18 مرداد 1393 برچسب‌ها: مقالات
Security Considerations for Cloud Computing (Part 6) - Metered Services
IRCAR201402202
Date: 2014-02-18

Introduction
In the first five parts of this series on private cloud security, we talked about some basic factors you have to consider that are specific to security issues in the private cloud. These issues are key to the essential characteristics of cloud computing and this sets them apart from the typical security considerations you would deal with in a traditional datacenter. And that leads us, in this sixth part of our series on private cloud security, to the final essential characteristic of cloud computing: metered services. It might well be the most controversial one, as well.
Why metered services?
Metered services is also often referred to as “pay per use.” In the enterprise, metering services is a means of accountability. Metered services is necessary to the “utility” aspect of cloud computing. People understand that they “pay per use” for true utilities such as electricity and water. The number of kilowatt hours or gallons of water you consume is measured by a meter that keeps track and each month the amount is reported back to the service provider, either through remote access, via so-called “smart meters”, or by a meter reader who manually inspects the meter and records the amount used.
Unlike in a traditional data center, where your main job is to “keep the lights on”, a private cloud environment is about providing services. You don’t want to merely keep the lights on; you want to keep the services running. This is all part of the private cloud principle of thinking of yourself as a service provider. And one of the major responsibilities that you have as a service provider is to be transparent about how much of the shared infrastructure a particular tenant uses, and the cost of that usage.
The cloud characteristic of metered service is critical because, as a service provider, part of your job is to help your tenants be good stewards of the shared pool of cloud resources. Those resources include the shared pool of compute, networking and storage resources. If the tenant has no awareness of the costs that are involved in obtaining resources from the shared pool, there will be no motivation on the tenant’s part to constrain the use of the resources and wastage is bound to occur.
This also motivates the consumers of the cloud services to think about what they actually need, instead of what they think they might need. For example, let’s take the example of uptime. Uptime is often expressed in terms of “9s.” So 99.99% is called “four nines,” 99.999% is “five nines,” and so forth. When you ask the typical tenant how many “9s” of uptime they need, they’ll invariably tell you “well, I need five 9s”. But do they really need those five 9s? What the person might not know is that, in order to provide that level of availability, the costs increase significantly and it puts a much greater strain on the shared pool of resources.
The essential characteristic of metered services is what enables you to provide the consumer of cloud services information with what the exact costs of five 9s turns out to be. Then the tenant can take those costs into consideration and compare that with what they calculate they would lose if they only had three 9s availability. It might turn out that the amount of money you lose with five nines availability is less than the cost of obtaining that level of availability. In that case, the tenant would be willing to accept a lower level of service because the overall cost is lower.
How metered services work in the private cloud
In a private cloud environment, you will need to track all chargeable use of the cloud services used by the tenants so that you can bill them. In some cases, mostly in enterprise environments, you won’t actually charge the tenants; instead you will do something called “show back”, whereby you provide reports of cloud service usage and what the services cost, but you don’t actually receive any money from the private cloud tenants. Even though the tenants aren’t actually paying in dollars, they are still accountable for the amount of resources they use.
From a security perspective, you need to ensure that tenants will not be able to bypass your monitoring systems in any way. One of the risks of bypassing the monitoring system is that the tenants might be able to reduce the amounts that they pay by adjusting the data to indicate that they are using less of the cloud infrastructure than they are actually using. This “cheating” isn’t just about money; it could potentially lead to a denial of services situation, since the tenant that is bypassing the monitoring system can acquire increasing amounts of cloud resources without any limit. If this happens, it might get to the point of exhaustion of the resource pool and then other tenants will not be able to obtain the resources they need when they need them.
While it is unlikely that a group within your organization would try to steal cloud services from the enterprise private cloud in this way, there is always the risk that someone could try to use the private cloud resources for unapproved purposes. Insider attacks are among the most common of security breaches, according to many studies, so it’s not unreasonable to imagine that a disgruntled employee might try to take advantage of the resources provided by the private cloud. Alternately, the employee might not even be disgruntled – it might just be someone who wants to use the resources for personal gain and avoid paying for them.
Of course, outside attacks can take place against the cloud infrastructure, as well. An attacker from outside the company might gain access to the private cloud in order to run a mail server. The attacker might use the mail server as a launch pad for spam or email based attacks, or even attempt to run a private commercial mail server to make money, all without paying for any component of the infrastructure. Of course, to make this a success, the intruder would have to avoid detection. In order to avoid detection, the intruder using the private cloud resources would have to bypass the monitoring and billing systems that are being used by the private cloud. Another alternative would be for the attacker to arrange for his unauthorized use to be paid for by a legitimate client, such as a business unit. These charges could even be spread out over a large number of tenants, so that the charges could go virtually unnoticed by the legitimate tenants of the private cloud. A good metering mechanism will help to prevent this.
Record keeping
Because metered services are so critical to the performance and availability of the cloud infrastructure, you need to ensure that all monitoring and logging facilities that measure and report on resource usage are protected from compromise. Logging must always be accurate and must always correctly identify who is using the resource. You need to ensure that access controls, which include role based access controls, are employed throughout your monitoring and reporting infrastructure.
You should provide tenants access to their billing information through the financial management systems you deploy in your private cloud, and they should include enough detail to enable your tenants to identify any possible unauthorized usage of resources on their behalf. Finally, you should put into a place a system whereby it is easy for the tenants to report to you if they find anomalies or inconsistencies.
Related Links:
References:

18 مرداد 1393 برچسب‌ها: مقالات
SQL Server Security- 3rd Section- Schemas
IRCAR201402201
Date: 2014-02-17
  1. Introduction
SQL Server has many features that support creating secure database applications. Common security considerations, such as data theft or vandalism, apply regardless of the version of SQL Server you are using. Data integrity should also be considered as a security issue. If data is not protected, it is possible that it could become worthless if ad hoc data manipulation is permitted and the data is inadvertently or maliciously modified with incorrect values or deleted entirely. In addition, there are often legal requirements that must be adhered to, such as the correct storage of confidential information. Storing some kinds of personal data is proscribed entirely, depending on the laws that apply in a particular jurisdiction.
Each version of SQL Server has different security features, as does each version of Windows, with later versions having enhanced functionality over earlier ones. It is important to understand that security features alone cannot guarantee a secure database application. Each database application is unique in its requirements, execution environment, deployment model, physical location, and user population. Some applications that are local in scope may need only minimal security whereas other local applications or applications deployed over the Internet may require stringent security measures and ongoing monitoring and evaluation.
The security requirements of a SQL Server database application should be considered at design time, not as an afterthought. Evaluating threats early in the development cycle gives you the opportunity to mitigate potential damage wherever a vulnerability is detected.
Even if the initial design of an application is sound, new threats may emerge as the system evolves. By creating multiple lines of defense around your database, you can minimize the damage inflicted by a security breach. Your first line of defense is to reduce the attack surface area by never to granting more permissions than are absolutely necessary.
The topics in this section briefly describe the security features in SQL Server that are relevant for developers, with links to relevant topics in SQL Server Books Online and other resources that provide more detailed coverage.
  1. Ownership and User-Schema Separation in SQL Server
A core concept of SQL Server security is that owners of objects have irrevocable permissions to administer them. You cannot remove privileges from an object owner, and you cannot drop users from a database if they own objects in it.
User-schema separation allows for more flexibility in managing database object permissions. A schema is a named container for database objects, which allows you to group objects into separate namespaces. For example, the AdventureWorks sample database contains schemas for Production, Sales, and HumanResources.
The four-part naming syntax for referring to objects specifies the schema name.
Server.Database.DatabaseSchema.DatabaseObject
Schemas can be owned by any database principal, and a single principal can own multiple schemas. You can apply security rules to a schema, which are inherited by all objects in the schema. Once you set up access permissions for a schema, those permissions are automatically applied as new objects are added to the schema. Users can be assigned a default schema, and multiple database users can share the same schema.
By default, when developers create objects in a schema, the objects are owned by the security principal that owns the schema, not the developer. Object ownership can be transferred with ALTER AUTHORIZATION Transact-SQL statement. A schema can also contain objects that are owned by different users and have more granular permissions than those assigned to the schema, although this is not recommended because it adds complexity to managing permissions. Objects can be moved between schemas, and schema ownership can be transferred between principals. Database users can be dropped without affecting schemas.

SQL Server ships with ten pre-defined schemas that have the same names as the built-in database users and roles. These exist mainly for backward compatibility. You can drop the schemas that have the same names as the fixed database roles if you do not need them. You cannot drop the following schemas:
  • dbo
  • guest
  • sys
  • INFORMATION_SCHEMA
If you drop them from the model database, they will not appear in new databases.
Note
The sys and INFORMATION_SCHEMA schemas are reserved for system objects. You cannot create objects in these schemas and you cannot drop them.

The dbo schema is the default schema for a newly created database. The dbo schema is owned by the dbo user account. By default, users created with the CREATE USER Transact-SQL command have dbo as their default schema.
Users who are assigned the dbo schema do not inherit the permissions of the dbo user account. No permissions are inherited from a schema by users; schema permissions are inherited by the database objects contained in the schema.
Note
When database objects are referenced by using a one-part name, SQL Server first looks in the user's default schema. If the object is not found there, SQL Server looks next in the dbo schema. If the object is not in the dbo schema, an error is returned.

References:
http://msdn.microsoft.com
18 مرداد 1393 برچسب‌ها: مقالات
Ensuring your SIEM system is working optimally
IRCAR201401200

Date: 2014/01/28

SIEM solutions are complex products and mostly take some effort to get working at optimal performance. In their design they are able to collect log and event data from multiple devices, apply procedures for real time correlation and direct alerts for discovered events.
SIEM is not without its challenges. Organisations are often frustrated with SIEM systems' effectiveness in their default configurations, yet never devote the time required to obtain the worth that SIEM can deliver. Initial deployment is the easy part however reaching the point at which SIEM is capable of delivering clear and substantial results requires your time and hard work. The organisation will need to spend time mapping the relationships between events and risks and creating the required logs, rules and correlations.
Areas that could be affecting SIEM performance:
  • Data collection, it’s important that a balance be found of data collection, storage and analysis
  • Volumes of data in some organisations are extremely high and with limited resources it makes data management overwhelming
  • Continual changing of user behavior i.e. social media, mobile devices and mobile computing
  • Increase of devices and applications in the workplace
  • Management of the monitoring system
  • Increased complexity of security threats
  • Inability to interpret the data
Steps towards achieving better performance
  1. Secure a SIEM team
Your monitoring is comparative to the quality of the team the organisation has assigned to the SIEM system. It’s important that the team responsible for managing, monitoring, configuring and extracting the required information from the logs is knowledgeable.
  1. Establish an effective monitoring program
  • Identify exposure and have a good understanding of your vulnerabilities and areas of security weakness
  • It helps to focus on the results or information you are trying to retrieve
  • Identify which systems or components to monitor in order of priority. By devising a list, the assets can be monitored according to areas of high risk taking precedence.
  • Consider integrating the SIEM into applications
  • Realise that some applications don’t generate log data that can be incorporated in the SIEM, this will save you a lot of hassle later on
  • Identify which events the organization should be alerted about and what information is required to be known with regards to the assets
  • If you are not finding all the information you require it’s essential that adjustments are made to the system through changing the logging levels or installing additional systems to provide the information you need
  • Ensure you collect data from a range of groups that may benefit from the collected log data
  1. Configuring your SIEM
  • Choose the first asset on the list to use as the initial setup component; the initial configuring will be the most cumbersome. To configure the asset/group correctly you will need a good understanding of the requirements, the components and the events of that particular group
  • Develop the policies/rules
  • Be prepared for false positives
  • By using a group with clear compliance requirements for the initial configuration the process will be a lot easier
  • Determine the events that will indicate noncompliance and breach of policy
  • Be open minded enough to construct a route whereby new SIEM capabilities could be added if necessary at a later stage
  1. Analysis
  • Analyse the systems associated with the asset
  • Systematically extract information form logs, event streams and systems to detect any security threats according to the events previously determined as non-compliant or a breach of security
  • Referential data is as important as the real time data. Data such as asset lists, vulnerability scan results and threat intelligence data. This data is important when it comes to prioritizing events and can save time during investigation
  • Place emphasis on correlation capabilities as this can help associate events that are not usually perceived by people
  • Once the SIEM has been implemented, the data that is being collected should be assessed periodically.
Conclusion
The decision to deploy SIEM depends on a number of factors, including business requirements, the available support personnel, network architecture, the maintenance window and bandwidth. To achieve the most of the SIEM technology, considerable initial effort would need to be applied. The SIEM system is as valuable as the effort put into understanding and using the system and without the effort of configuration it is merely a log manager. SIEM technology with its ability to automate log monitoring, pattern recognition, alerting, forensics and correlation it is the way to a well-run and mature IT operation.
18 مرداد 1393 برچسب‌ها: مقالات
صفحات: «« « ... 3 4 5 6 7 ... » »»