UNIVERSITI KUALA LUMPUR

MALAYSIAN INSTITUTE OF INFORMATION TECHNOLOGY

INCIDENT HANDLING & RESPONSE (IKB42003)

L01-B02
(SEMESTER JANUARY 2016)

LECTURER NAME:
MISS DELINA BEH MEI YIN

1
2
3
4

NAMES:

ID NUMBERS:

MUHAMMAD SYAZWAN BIN ISMAIL

ARIFF AFFANDI BIN AZMAN
MOHAMMAD IZRIN BIN ABDUL RASHID
MOHAMMAD IZAMMUDIN BIN MOHD ROSLI

( 52215114122 )
( 52215114004 )
( 52215114256 )
( 52215114268 )

CASE STUDY 1
1. What risk does the employees faced with the leaked out data regarding their personal
information?
Answer :
The first risk that the employees faced when the leaked out data is data theft by
intruders which is deliberate attacks on systems and individuals who have access to
sensitive data including personal information can cause more harm than inadvertent
exposure. For example, former employees who hold a grudge against an institute, or
criminals that looking to make money from the sale of the data will look for data
stored on any electrical devices.
The second risk that need to be faced by the employees when the leaked out data
happen is passive reconnaissance which is attacker/hacker attempt to gain
informations about targeted computers and networks without actively engaging with
the systems. The purpose of this attack is simply to obtain information, rather than to
actively exploit the target. However, passive reconnaissance is often a preliminary
step towards an active attempt to exploit the target system.
The third risk that the employees faced is malware that have been classified as a zeroday threat, and there is no signature yet available, there is a higher likelihood that the
malware will evade inbound gateway protection measures and desktop anti-virus. If
the malware infects the pc or the server, it may then initiate outbound
communications, potentially sending out files which may contain sensitive data.
The last risk that have be faced by the employees is SQL injection which is attacker
can execute malicious SQL statements that control a web applications database
server. Further trial and error by the attacker could eventually reveal table names,
field names, and other information, once obtained, will allow them to construct an
SQL query within the POST element that yields sensitive data. A successful SQL
injection exploit can read and collect the sensitive data from the database, and modify
database data.

2. What steps that could be taken by the university to reduce the same incident from
happening again?
Answer :
Keeping networks safe.
For several reasons, security pros in educational institutions have turned to network
access control (NAC) technology to help keep their networks safe. For one thing,
NAC can ensure that only authorized users running up-to-date PCs can access
university networks. They also give school IT staff tools to limit the resources
authorized users can access from various locations around campuses.
Comprehensive data sanitization.
Web sites must filter all user input. Ideally, user data should be filtered for context.
For example, e-mail addresses should be filtered to allow only the characters allowed
in an e-mail address, phone numbers should be filtered to allow only the characters
allowed in a phone number, and so on.
Use a web application firewall.
A popular example is the free, open source module ModSecurity which is available
for Apache, Microsoft IIS, and NGINX web servers. ModSecurity provides a
sophisticated and ever-evolving set of rules to filter potentially dangerous web
requests. Its SQL injection defenses can catch most attempts to sneak SQL through
web channels.
Limit database privileges by context.
Create multiple database user accounts with the minimum levels of privilege for their
usage environment. For example, the code behind a login page should query the
database using an account limited only to the relevant credentials table. This way, a
breach through this channel cannot be leveraged to compromise the entire database.

Avoid constructing SQL queries with user input.

Even data sanitization routines can be flawed. Ideally, using SQL variable binding
with prepared statements or stored procedures is much safer than constructing full
queries.