What Is Email Security?
What Is Email Security?
What Is Email Security?
Email security can be defined as the use of various techniques to keep sensitive
information in email communication and accounts secure. These precautions
are taken chiefly against unauthorized access, loss, or compromise. It allows an
individual or an organization to protect the overall access to one or more email
addresses or accounts.
Email security safeguards the content of an email account or service that
generally serves as a popular medium for the spread of malware, spam, and
phishing attacks. This is usually done using deceptive messages to entice
recipients to divulge sensitive information, open attachments, or click on
hyperlinks that install malware on the victim’s device.
Stopping attacks at the entry point:
Email is also a common entry point for attackers looking to gain a foothold in an
enterprise network and breach valuable business data. Hence, email security is
necessary for both individual and business email accounts, and there are
multiple measures organizations should take to enhance email security. Some of
the proactive email security measures, from an end user’s standpoint, include:
1.
1. Strong passwords
2. Password rotations
3. Spam filters
4. Desktop-based anti-virus or anti-spam application
Similarly, a service provider ensures email security by using strong passwords
and access-control mechanisms on an email server. Here, the email messages
are encrypted and digitally-signed as they are placed in the inbox or are in transit
to or from a subscriber’s email address.
The service provider also implements firewall and software-based spam filtering
applications to restrict unsolicited, untrustworthy, and malicious email messages
from being delivered to a user’s inbox.
Automated Email Encryption
Deploying an automated email encryption solution is one of the best practices in
today’s modern organizations. This encryption solution should analyze all
outbound email traffic to determine whether the material being communicated
over email is sensitive. If the content is sensitive, it needs to be encrypted before
it is emailed to the intended recipient. Such a mechanism will prevent cyber-
attackers from viewing emails, even if they were to intercept them.
Here’s why an enterprise should employ email encryption:
1.
1.
1. To protect confidential information
2. To stay in compliance
3. To avoid additional security breaches
4. To stay authentic
2. Back-up critical files
Although an effective enterprise email security strategy drastically reduces an
organization’s chances of experiencing a cyber-attack, no security strategy or
potential solution is entirely foolproof. To minimize the potential damage and
devastation in a ransomware attack, enterprises should back up critical files
regularly and automatically.
The organization should be aware that sophisticated ransomware variants may
sit idle for weeks without any activity until triggered, potentially destroying
backups and all the critical files. With advanced technology, threat actors are
also getting smarter as they attack backups to prevent recovery. However, there
are various ways that enterprises can protect their backups, which include:
1.
1. Back-up supplement: Keep additional copies in multiple
locations.
2. Isolate backups: The more the barriers between a
compromised system and its backups, the harder it will be for a
ransomware-type threat to attack these backups.
3. Frequent backup tests: Restoration exercises should be
performed regularly to identify any issues or potential
vulnerabilities.
3. Educate employees
Employee education and security awareness training are essential aspects of an
effective enterprise email security strategy. Administrators, IT, and corporate
professionals understand the importance of corporate email security, the value
of sensitive data, and the consequences of a successful phishing attack or
breach.
Yet, the employees must share this understanding with their
colleagues. According to a Global report 2018, most insider breaches result from
human error or negligence, and enterprises can mitigate this risk by sharing
knowledge with employees and providing periodic awareness training.
As employees are an enterprise’s first line of defense, it is important to provide
regular, comprehensive security training. This will not only minimize the risk of
human error but also strengthen this critical defense.
4. Email accounts protection with sender authentication
According to Verizon report 2018, 90% of data breaches involve phishing. Sender
authentication using cryptographic standards and protocols helps prevent
phishing attacks and protect email accounts against other threats like email
spoofing and business email compromise (BEC) by providing a way to verify that
an email actually comes from a legitimate sender. The email authentication
standards commonly used for making this verification possible are:
1.
1. Sender Policy Framework (SPF) – an open standard that
specifies a method for preventing sender address forgery,
2. Domain Keys Identified Mail (DKIM) – provides an encryption
key and a digital signature that verifies that an email message
was not faked or altered, and
3. Domain-based Message Authentication, Reporting &
Conformance (DMARC) – unifies mechanisms used in SPF and
DKIM, allowing domain owners to declare how they would like
an email from that domain to be handled if it fails an
authorization test.
Like any security aspect, in-depth defense is key to effective protection, and
sender authentication is no exception. Hence, sender authentication should be
implemented as part of a comprehensive cloud email security solution by any
organization.
5. Extra protection against credential phishing in Office 365 with multifactor
authentication
Microsoft Office 365 is a popular platform among enterprises, and its email
system is now a bigger target for cyber-criminals. According to Cyren and
Osterman Research’s report 2019, 40% of Office 365 customers have
experienced credential theft, despite its security protection. Therefore, additional
protection for Office 365 is required for enterprises to protect from credential
phishing attacks and account takeovers.
Office 365 email security relies upon in-depth defense. Microsoft’s basic email
security features, including their Microsoft Exchange Online Protection (EOP), are
solely dependent on traditional filtering techniques, which are ineffective against
today’s targeted, sophisticated, and advanced technological attacks. Thus, an
enterprise needs to look for an advanced cloud email security solution that
provides additional layers of intuitive, real-time protection and complements the
default security provided within Office 365.
In situations where a corporate email account’s credentials are successfully
stolen, multifactor authentication (MFA) can prevent an attacker from gaining
access to the account and wreaking havoc in the organization.
6. Secure email gateway
Secure Email Gateway
One of the best practices that organizations should put into effect is
implementing a secure email gateway. An email gateway scans and processes
all incoming and outgoing emails and makes sure that threats are not allowed in.
As the attacks are growing in sophistication, standard security measures, such
as blocking known harmful file attachments, are no longer effective. Hence, a
better solution is to deploy a secure email gateway that uses a multi-layered
approach, wherein all the email traffic passes through the gateway to ensure its
authenticity.
7. Strategize for the worst-case scenario
Having a clear and systematic protocol in place for responding to potential
threats can help minimize the damage. For example, if an employee’s email
account is compromised, all involved parties must know who to notify. To handle
potential cyber-attack, the organization should plan for the worst-case. Do all the
parties need to be aware of how to respond to a threat in the case of a breach?
Acting fast is critically important in the event of a cyber-attack. Having an exact
protocol in place will help eliminate possible confusion or delays – since the
more the delay in action, the greater the damage.
8. Team up with an enterprise-level security provider
Teaming up with an expert in the email security industry provides an excellent
chance for the enterprise to receive next-generation email protection at a
discounted price and other benefits like priority support services, new revenue
opportunities, technical, marketing, and sales training, and additional guidance.
One such enterprise-level security provider is Guardian Digital that provides a
highly advantageous Worldwide Partner Program capable of delivering greater
email security and profit benefits.
In Conclusion
A robust email security system can help both the organizations and employees
create a safe working environment as the email system works in coordination
with the enterprise’s overall workflow and processes. Implementing an effective
enterprise email security strategy may seem complicated and overwhelming, but
prioritizing the fundamentals correctly may prove to be a boon for any
organization. Without appropriate email security measures, an organization will
always be vulnerable to email-borne threats, regardless of other advanced
technology it has deployed.
Trusted systems
One way to enhance the ability of a system to defend against intruders and
malicious programs is to implement trusted system technology.
1. Data access control
Following successful logon, the user has been granted access to one or set of
hosts and applications. This is generally not sufficient for a system that
includes sensitive data in its database. Through the user access control
procedure, a user can be identified to the system. Associated with each user,
there can be a profile that specifies permissible operations and file accesses.
The operating system can then enforce rules based on the user profile. The
database management system, however, must control access to specific
records or even portions of records. The operating system may grant a user
permission to access a file or use an application, following which there are
no further security checks, the database management system must make a
decision on each individual access attempt. That decision will depend not
only on the user‟s identity but also on the specific parts of the data being
accessed and even on the information already divulged to the user.
A general model of access control as exercised by an file or database
management system is that of an access matrix. The basic elements of the
model are as follows:
· Subject: An entity capable of accessing objects. Generally, the
concept of subject equates with that of process.
Object: Anything to which access is controlled. Examples include
·
files, portion of files, programs, and segments of memory.
· Access right: The way in which the object is accessed by a subject.
Examples are read, write and execute.
One axis of the matrix consists of identified subjects that may attempt data access.
Typically, this list will consist of individual users or user groups. The other axis
lists the objects that may be accessed. Objects may be individual data fields. Each
entry in the matrix indicates the access rights of that subject for that object. The
matrix may be decomposed by columns, yielding access control lists. Thus, for
each object, an access control list lists users and their permitted access rights. The
access control list may contain a default, or public, entry.
Decomposition by rows yields capability tickets. A capability ticket
specifies authorized objects and operations for a user. Each user has a
number of tickets and may be authorized to loan or give them to others.
Because tickets may be dispersed around the system, they present a greater
security problem than access control lists. In particular, the ticket must be
unforgeable. One way to accomplish this is to have the operating system
hold all tickets on behalf of users. These tickets would have to be held in a
region of memory inaccessible to users.
2. The concept of Trusted Systems
When multiple categories or levels of data are defined, the requirement is
referred to as multilevel security. The general statement of the requirement
for multilevel security is that a subject at a high level may not convey
information to a subject at a lower or noncomparable level unless that flow
accurately reflects the will of an authorized user. For implementation
purposes, this requirement is in two parts and is simply stated. A multilevel
secure system must enforce:
· No read up: A subject can only read an object of less or equal security level. This
is referred to as simple security property.
· No write down: A subject can only write into an object of greater or equal
security level.
This is referred to as *-property (star property).
Accountability
On a trusted system, all actions can be traced to a responsible person. Most UNIX
systems lack good accountability because some actions cannot be traced to a person.
For example, pseudo-user accounts, such as lp or cron, run anonymously; their actions
can be discovered only by changes to system information. As described later, a trusted
UNIX system improves accountability by associating each account with a real user,
auditing every action, and associating each action with a specific user on the system.
On a typical UNIX system, each process has a real and effective user ID as well as a
real and effective group ID. A process with the effective user ID set to root can set
these identifiers to any user. The C2 level of trust requires that the TCB be able to
identify each user uniquely and thus enforce individual accountability. The concept of
user identity is expanded on trusted UNIX systems to add a separate identifier called
the ``login user identifier'' (LUID). The LUID is an indelible stamp on every process
associated with a user. The LUID identifies the user who is responsible for the
process's session. Once stamped, the process's LUID cannot be changed by anyone.
Child processes inherit the LUID of their parent.
Discretionary access control
Discretionary access control (DAC) determines whether a user has access to desired
data. That information is within an ``object'' (file, device, and so on) that the user's
process is trying to use. On most UNIX systems, object protection is enforced through
the relationship between the user and the group of a process and the owner, group and
other mode bits of the object. The protection attributes of these objects are at the
discretion of the object's owner, who can change the protection bits on a file and even
give the file away (change ownership). Your SCO OpenServer system extends the
standard discretionary access control rules used by the UNIX file permissions by
restricting the:
ability to set the SUID and SGID (set user or group ID on execution) bit on files.
ability to change ownership of files with chown(C).
potential misuse of SUID, SGID, and sticky* permissions by clearing these bits
whenever a file is written.
Footnotes
*
This term comes from an earlier versions of UNIX systems where this
permission bit (also called text-save) caused a file to be held in memory. Thus
the expression ``sticky.''
Object reuse
As required by the C2 level of trust, SCO OpenServer systems always clears the
information in a storage object (memory, whether in RAM or secondary storage)
before re-allocating the resource. This prevents users from gaining access to residual
data belonging to other users.
Privileges are stored in an ``privilege set'' associated with every process. Thi is a list
of privileges which allow a type of action if the privilege is present, and do not allow
the action if the privilege is absent. Privileges are either set by the system defaults or
defined for a specific user.
SCO OpenServer systems extend the standard UNIX system I&A mechanisms. There
are more rules enforcing the types of passwords that can be used. There are new
procedures for generating and changing passwords. The location and protection of
certain parts of the password database differs from that of other UNIX systems. The
administrator also has greater control over the login process. A separate role, called
authentication (or accounts) administrator (with subsystem authorization auth), is
charged with account administration.
Auditing
Most UNIX systems keep a limited record of system actions with their accounting
subsystem. The accounting subsystem writes a single accounting record upon
completion of each user process. SCO OpenServer systems provide an extensive
series of records that form a ``trail'' of actions. In this trail is a record of every access
between subject and object (successful and unsuccessful) and every change of subject,
object, and system characteristics. The audit subsystem is controlled by a separate role
called audit administrator (with subsystem authorization audit). The audit
administrator decides how much information is recorded, and how reliably it is
recorded and maintains the information once it is collected. The audit subsystem
provides the audit administrator with an extensive history of system actions. This
helps the administrator to identify what happened to the system, when it occurred, and
who was involved.
Protected subsystems
UNIX systems provide the SUID and SGID mechanisms that allow programs to set
the user of group ID of a process with the setuid(S) and setgid(S) system calls and
permission bits described in chown(C). With these you can construct programs that
maintain protected information. This information can only be accessed or modified by
the operations implemented in the programs. The TCB defines several protected
subsystems. Each of these subsystems consists of a collection of private information
(files and/or databases), any related devices, and the utilities and commands used to
maintain that information. The protected subsystems use the SUID/SGID mechanisms
to protect their private files, databases, and devices from unrestricted access. The
trusted system extends the notion of a protected subsystem in several ways:
It provides more precise control of users and groups who maintain certain
collections of system resources (private information).
It keeps a separate database of users allowed to run the programs that
maintain the private information.
It does not require users to log in as the subsystem administrator but rather
uses the database to check the subsystem authorization. This satisfies the full
accountability requirement for all actions performed by subsystem
programs. (If users log in to anonymous accounts to perform system
administration, there is no way to determine who performed a given action.)