Miscellaneous Security

Reading time: 2 – 3 minutes

Photo: jaeming

Being security aware and security conscious often boils down to understanding three key concepts that are common to risk management

These security concepts have been around since the inception of information security. Although, these are high-level generalizations, they are important for everyone to know about.

This article is focused on understanding how each of these apply to information systems.

Confidentiality

Confidentiality loss happens when information can be viewed (read) by individuals who shouldn’t access it.

Loss of confidentiality can happen physically or electronically.

Electronic confidentiality loss can happen when the clients and servers aren’t encrypting their communications. This allows malicious entities to view private communications.

Physical confidential loss can happen through social engineering or through theft. This typically means having laptops stolen.

Integrity

Integrity loss happens when information is modified without the modification being authorized. This doesn’t mean that an unauthorized party has to cause the integrity loss to happen. The integrity loss due to an authorized party doing something they shouldn’t. An example would be a system administrator deleting an account record they weren’t authorized to delete.

Integrity Loss can happen either accidentally or through malicious intent. Malicious integrity loss can happen when a user purposely adds, deletes, or modifies database records. This can occur either through an authorized party (someone who has the access to actually modify the record) or by an unauthorized party when the user has access that they shouldn’t have.

Accidental integrity loss happens when a system modifies or deletes records that it shouldn’t. This can happen when a virus infects a system or when a user does something that he didn’t intend to do. This is often why systems will verify that you want a file deleted, before it actually does so.

Availability

Availability is the simple idea that when a user or system attempts to access something, it is available to be accessed. This is extremely important for mission critical systems. Availability for these systems are so critical that most companies have business continuity plans (BCP’s) in order for there systems to have redundancy.

Just like confidentiality and integrity loss, availability loss can happen by accident, a car crashing into a fiber pole disabling access to a system, or through malicious intent, such as a Denial-of-Service attack.

Reading time: 2 – 3 minutes

Photo: Jason Arends

This is the ninth-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What are Insecure Communications

Insecure communications is when a client and server communicate over a n0n-secure (non-encrypted) channel. By doing this, the developer is ensuring that their communication channel can be viewed by eyes they didn’t intend.

Failing to securely communicate server-to-server and server-to-client helps attackers to intercept sensitive transactions. Attackers do this by using man-in-the-middle attacks, a post for another time. Not communicating securely breaks down confidentiality and integrity.

Developers fall into communicating insecurely when they:

• Don’t secure their client-to-server connections.
• Don’t secure their server-to-database connections.
• Don’t secure other back end connections that pass sensitive data.

An Example of Insecure Communications

Assume a developer has written an application that takes input from a user and stores it in a database that is located on another network segment.

If the developer fails to use SSL between the web server and the user, then he has an insecure communications channel between the user and the web server. (Client-to-server connection)

If the developer fails to forget to encrypt the connection between his web server and the database, then he is failing to secure the server-to-database connection.

How Do You Prevent Insecure Communications from Occurring in your Web Application

To prevent insecure communications from occurring, the first step is to make sure the security architect has formulated secure methods of communication between the clients and servers. The security architect can limit the connections they need to look at by only reviewing which servers and clients pass sensitive data.

Keep in mind, most of these architectures will fail to forget to encrypt data on back-end connections, such as database connections. Just because the data is now behind a firewall doesn’t mean it should be passed in clear-text.

To verify insecure communications won’t happen on your network:

• Make sure all client-to-server connections are encrypted with SSL.
• Verify that server-to-database connections are encrypted.
• Verify that any other areas in the design where sensitive data is passed is done so in a secure way.
• Keep developers in a security mindset. Developers should never assume their application is sending their information securely. Developers should always assume that any communications that are being made are done insecurely.