In a Galaxy Far, Far Away

Back when we first added this section in 2014s DBIR, we noted the evolution
of this pattern dating back prior to 2012 and the new waves of DoS attacks
peeking out from the horizon.
Rarer are the days where the DDoS bot recruitment pool is limited to our
parents 15 year-old home desktopthe one that haunts all your family visits
like Banquos ghost, breathing its foul contagion on all who dare attempt to
patch it. As the attackers botnets popped their steroids for a beefier blow,
the attackers began to realize their creativity and scope should not be so
limited. This epiphany has resulted in script injections into browser sessions,
distributed reflective DoS attacks, as well as the infancy of temporal lensing28
(which sends packets via different paths with a focus on time so that they
arrive simultaneously in order to overwhelm the target system). Not only are
these attacks increasing in scope, but also in number. We received the gory
details of DDoS attacks (e.g. bytes and packets per second, duration) from
Akamai Networks, Arbor Networks, and Verizon DoS Defense. We will get into
magnitude and duration in a little bit but first, lets examine density. As
provided in the last two reports, Figure 41 shows two density plots of
bandwidth and packets in DoS attacks, respectively. In this years dataset, we
see that the means of bytes per second versus packets per second were
5.51Gbps and 1.89Mpps respectively.

Try this on for size. Our analysis showed that attacks are either large in
magnitude (i.e. packets per second), or they are long in duration, but they are
typically not both, and frequently neither as depicted in Figure 42. Larger-
sized attacks pull away from the origin and yet remain parallel to the y-axis.
Thus, the data revealed
predictability of whether the attack would be either a thundering exclamation
or a conversation that seems to never end, by just looking at the very
beginning of the attack.

With density, magnitude and duration out of the way, lets finally look at
enumeration of packets per second (pps) by industry and a caveat that comes
with it. We compared the max and median number of pps per industry and as
expected, they varied quite a bit. For example, although one of our large
datasets showed that Media had the highest number (222 million pps)
throughout this years data, it doesnt necessarily mean (no pun intended)
that it is the industry youd expect to run out the door with their pants on fire
every
time. To see this, just look at Figure 43 that reflects the median number of pps
for Media (approximately 600,000). Another such case includes High Tech
Consulting, where the max pps was around 214 million, yet the median was
around 540,000. In general, we dont always want to look at the max as it may
only point to a single event, not all events throughout the entire year, hence
we need to consider the median.

To sum up, They start wanting me to care more, and I just dont works for
good ol Han, but unfortunately we cannot live by his motivational motto
when it comes to DoS. Not only is it one of the most popular attack types out
there, but the rise to dominance of DoS is forcing attackers to join the dark
side in droves; it may be time for Han, and the rest of us, to have an abrupt
paradigm shift.

Recommended controls
Fear not the lone wolf. Isolate key assets to help prevent your devices from
being used to launch attacks. For instance, enforce the principle of least
privilege, close any ports that are not necessary andbottom lineif you
dont need it, turn it off. Also, prepare your den for potential attacks. Patch
your servers/services, use your
IDS/IPS to identify and block bad traffic, use your firewalls to help filter, and
have a response plan ready.

Walking around with your head in the clouds It makes sense as the peak size,
complexity and frequency of DoS attacks continue to evolve and rise, that
cloud service providers must have solutions in
place in order to protect the availability of their services and infrastructure.
Understand the capabilities of your defenses.
Have a solid understanding of your DDoS mitigation service-level agreements.
Make sure that your own DoS response procedures are built around existing
denial of service protections and your operations teams are trained on how to
best engage and leverage these services if and when they become more than
just a piece of mind control.

CE-2: DDoS attack the 12000 Monkeyz (page 61)

Impact and threat: Availability

A Denial of Service (DoS) attack involves a single computer using its network
connection to flood a targeted system or resource with traffic. Distributed Denial of
Service (DDoS) attacks leverage large numbers of systems to disrupt network
operations across large networks. Ergo, it denies the users of the systems
availability.

Case Study:
The eUP Project Team said the Student Academic Information System was subjected
to a denial of service attack that overloaded the system and rendered it unstable.

MANILA, Philippines The team behind the online student information system of the University of the
Philippines claimed to have suffered a form of cyberattack that supposedly resulted in problems during
the enrollment period in some of the campuses since last week.

In a statement, Annette Lagman of the eUP Project Team said the Student Academic Information System
(SAIS) was subjected to a denial of service (DoS) attack that overloaded the system and rendered it
unstable.

A DoS attack is an attempt to make an online service unavailable by overwhelming it with traffic from one
or more sources, said Lagman.

We strongly condemn this attack that has disrupted the enrollment process, causing great distress to our
students and their families, faculty members, and staff. We stand in solidarity with all the affected
members of the UP community, she added.

SAIS is part of the multi-million peso eUP project of the current university administration. It sought to
replace and harmonize existing online enrollment and student information systems of all campuses of the
university.

Problems were encountered during its initial rollout at the Los Baos campus, resulting in the downtime of
the system that prompted students to camp out to be able to access the system within the campus
network.
In its statement, eUP said SAIS received about four million hits over the past two days.

In response, access was temporarily confined within the UP network to prevent possible damage, said
Lagman.

But responding to the claim, Ralph Ignacio of UP Dilimans computerized registration system (CRS)
compared the number of visitors of the enrollment system of the university's flagship campus, which has
yet to adopt the new system.

1.6 million hits taken by CRS today did not cause great distress to students and their families. In fact,
enrollment in UP Diliman is normal and as usual, he said in a Facebook post.

Probe sought
In Congress, Kabataan party-list Rep. Sarah Elago filed a resolution seeking an investigation of the
project.

SAIS uses proprietary software from Oracle and has reportedly cost over P24 million for the initial roll-
out. It should be noted that the various UP units, including UPLB, already have registration systems that
function way better than SAIS and cost just a fraction of the current system, she said.

What is puzzling is why the Pascual administration is pushing for this program despite it wasting too
much public funds and its clear incapacity to efficiently serve students. We need to see if UP was
shorthanded in entering this contract with private entities, and even if graft and corruption was committed
in pushing for this project to continue despite its clear failure to serve its purpose, she added.

Various student councils across the university also called for the junking of SAIS amid problems
encountered during the enrollment system.

KASAMA sa UP therefore calls on the UP Admin to junk SAIS, to uphold existing information systems
and oppose the commercialization of UP education by eUP that misuses public funds for exorbitant and
dubious transactions with foreign corporations despite the presence of locally competent experts that
have created the existing online registration systems of the university, a statement from an alliance of
student councils read.

The UP Office of the Student Regent also started a probe over the incident.

In an earlier statement, eUP apologized over the problems with the system.

No one is more regretful for this lapse than we are as implementers of this system. However, we stand
by the belief that with its continued use and your support, SAIS will improve and scale greater heights of
quality, reliability, and operational efficiency, it told university staff and students.

We understand the gravity of the situation, and we empathize with everyones frustration. It seems our
team and partner ePLDTs efforts to remedy the situation did not meet your expectations, and for that, we
sincerely apologize, it added.
Long lines in Diliman
While not directly affected by issues over SAIS, students also had to line up for hours at the UP Diliman
campus to enlist subjects for the incoming school year.

Student publication Philippine Collegian said students spent the night on Monday in the campus to ensure
slots for subjects.

UP Diliman Chancellor Michael Tan earlier told The STAR that the university will implement a block
system for new students to address problems in securing subjects.

The new system does not cover old students, said the UP official.

Bacground:

What is the CRS?

The Computerized Registration System of UP Diliman is a web-based
information system (accessible through the Internet) developed entirely by
students and graduates of the University to enable streamlined and
seamless operations, record-keeping, and decision support for the University.

The CRS is composed not only of registration-related modules, but extends to

integral
functions, including the processing and tracking of students' academic
records, finance-related transactions (e.g., loans, scholarships, etc.), and
other essential transactions and operations encompassing the entire
academic life cycle of the studentfrom admission to graduation, and even
beyond.
The original vision of the CRS, as the name suggests, was merely to facilitate
the very tedious registration process of the University through
computerization. However, as modules were being developed and
successfully deployed, there came a steady emergence of ideas for new
functionalities, ranging from the automation/computerization of established
manual practices/procedures, to the
introduction of entirely new concepts and innovations, all in pursuit of an
enhanced university experience not only for the students but also for the
faculty members, administrators, and the University staff.

The Evolution of the CRS

When the first generation of the registration software application of the
University was
implemented in the late 1990s, the objective was just to facilitate the
Advance Freshman Registration (a registration activity that caters to
incoming freshmen of the University and is carried out a month earlier than
the regular registration). The application's sole function was to assist in the
enlistment of freshmen students into their classes, and the rest was done
manually, including a process that was called proof-reading. The
application was not yet web-based nor was it accessible through a local area
network, and so data was transferred from machine to machine through the
use of diskettes.
The name Computerized Registration System was coined for the second
generation of the registration software system. This system already
introduced the concept of preenlistment (an enlistment scheme that is still
used in the present version of the CRS). However, since the system was not
yet directly accessible to students through the Internet, the students had to
manually submit to the Electronic Data Processing (EDP) section of the Office
of the University Registrar (OUR) their desired classes, which were then
encoded by the staff into the system for batch processing (i.e., assignment of
class slots using a random system to select students who have chosen
classes with more demands than available slots). The rest of the registration
procedures were still done manually.

When University webmails became available for use, the CRS was made
accessible to the students through the use of their webmail log in
credentials. The new CRS was now web-based and could be accessed
through the Internet; and so students were now able to submit their desired
classes electronically. However, the computerized aspect still ended with
the preenlistment process, and the rest of the registration procedures were
still done manually.

Then, a new feature was added to the software systemthe electronic

submission of grades (which was then called the Student Records System
or SRS). The addition of this new feature presented the need for the
electronic storage of the students' registration information (particularly, the
final list of students in all of the classes upon conclusion of the registration
period) so that grades could then be entered into the system.

Due to this requirement, encoding features had to be added into the

system which allowed the EDP staff to enter the registration information of
all students from the OUR's copy of the Certificate of Registration or Form 5
(note: the Form 5 then was still accomplished manually by the students after
completion of the enlistment process and before the validation/checking of
enlisted classes, assessment of fees, and payment, which were still all done
manually at that time).

The new process required that the preenlistment data be wiped-out first
before the encoding started; then the actual encoding had to be carried out
in three phases and took months to completebut then again, it enabled the
very important feature of grades encoding.

The first version of the grades encoding feature, however, was still not
accessible to the faculty, but instead was also encoded by the EDP staff upon
the faculty's submission of the manual grade sheets. Eventually, a new
version was implemented that allowed the faculty to submit grades
electronically by logging into the SRS using the faculty webmail log in
credentials. The encoded grades were now available to the students through
a grades viewing module in the SRS.

At this point, the CRS management felt that the CRS/SRS modules were ripe
enough and proposed to distribute the applications to the other constituent
units (CUs) of the UP System. The CRS/SRS modules that are now being used
in some CUs are enhancement versions of the systems developed by the
former CRS team of UP Diliman.

In the summer of 2007, however, a new registration information system

emerged (initiated by an all new management team). The authors of the
system called it the University Information System or the UIS (however, since
the users were more accustomed to the name CRS, the system became
known as the Blue CRS due to the color scheme used). The distinguishing
feature of the Blue CRS was that all the modules available to a user could be
accessed by the user within a single application
upon log in (unlike in the older versions of the system wherein the user had
to log in to each module).

The first launch of the Blue CRS introduced the real-time enlistment
wherein students could enlist themselves in classes in real-time (i.e., on a
first-come-first-served basis) as an addition to the preenlistment wherein
students submitted their desired classes and the system performed the
batch processing to assign the class slots to students in a random fashion.
However, the real-time enlistment experience of Summer 2007 fell short of
the users' expectations and could not be considered successful by the
stakeholders, that is why it was never used again after that except for the
trimestral programs of the College of Business Administration (which
typically involves around 200 students only per trimester).

A very important innovation introduced in the Blue CRS was the E-Prerog
which converted the manual (i.e., pen-and-paper) enlistment into an
electronic enlistment (i.e., through the use of the electronic class list). Each
of the academic units that offered classes now had real-time access to the
electronic class lists of the classes they offered and entered students into the
class lists through the EPrerog module. This feature eliminated the need for
the very tedious three-phase encoding process performed by the EDP and, in
fact, it actually eliminated the need for the EDP altogether, since student
enlistments were now being entered in a decentralized fashion.

Other features/modules introduced in the Blue CRS were the encoding of

priority students (limited only for OUR use), student's ineligibility encoding
(limited only for college staff use for the encoding of academic deficiencies),
generation of the True Copy of Grades (available to colleges), the system-
generated Form 5A, report generation for class/subject demand statistics,
and freshmen-specific
modules (support for partial and full freshman blocks and a special module
for RA-assisted freshman enlistment). Other registration procedures were still
done manually.

In July of 2008, a new management team took over the CRS development.
The team assessed the condition of the CRS (including the features/modules
available and the internal workings of the system) and found that it needed
restructuring in order to perform optimally and support more complex
modules (the database structure of the Blue CRS was inherited from the
older versions of the system).

Furthermore, the Blue CRS had architectural deficiencies that limited the
flexibility to support crucial features (e.g., having more than one term open
for a module at one time) and hampered a speedier progress of module
development (e.g., each module developer had to handle security checking,
session management, etc.), among other difficulties.

The new management team decided that a new CRS must be created from
scratch (i.e., with new database structure and architectural design) in order
to support the team's vision of a comprehensive registration and student
records management system.
However, the new team recognized the need to be more thoroughly
acquainted with the procedures that would be supported in the new CRS
before going ahead with the implementation of the new system. And so, the
team decided to get immersed into the academic system by enhancing the
Blue CRS first before creating a whole new version.

From the start of the team's takeover until the 2nd Semester 2009-2010
registration, the team added more modules/features into the Blue CRS: E-
Prerog enhancements to minimize the encoding errors, enhanced
Preenlistment that supported ranking of desired classes and auto-
cancellation of conflicted classes, partial support for Change of Matriculation,
RA Accounts Management module to allow academic units to assign some
encoding capabilities to registration assistants, Class Redistribution module
to allow academic units to redistribute students among classes without
having to go through Change of Matriculation, Grade Submission
enhancements to support printing of the draft grade sheets and blocking of
unpaid students, and other enhancements in the Class Submission, Priority
Encoding, and Ineligibility modules.

Aside from the Blue CRS modules, the team also decided to create a
Cashiering system that connected to the CRS database to enable the real-
time update of the student's enrollment status once the payment is made at
the payment centers. This Cashiering system also generated the financial
reports that were needed by the Accounting office from the payment data
recorded in the CRS. In the Summer
of 2009, a new feature was incorporated into the Cashiering system that
allowed students to pay at designated banks wherein the deposit slips were
used to validate the payments, using a Bank Validation module, in order to
be reflected in the CRS records.
Another realization of the new management team was the fact that the
developers were being unnecessarily burdened with the task of correcting
(by directly accessing the database) the data anomalies caused by the
encoding errors (that were introduced before the module enhancements
were implemented). This prompted the conceptualization of modules that
would allow the appropriate offices' staff to update the CRS data themselves,
which eventually led to the creation of a separate OUR
Admin site that was accessible only to OUR staff. The site then expanded to
support not only data correction modules (e.g., Class List and Grades
Override) but also other crucial OUR functions:
Admission, Subject Crediting, Student Records Updating, Faculty Members
Database, Appeals for Late Registration, Certificate of Grades Generation,
Freshman Blocks Planning, and user support modules including Accounts
Management and Accounts Cloning (to aid in module-use investigations).

While creating/enhancing the said modules, the team was also already
starting with the
planning, architectural design, and implementation of a whole new system
that would eventually completely replace the Blue CRS.

Finally, in the Summer of 2010, the New Maroon CRS was launched for use.
This newest version of the CRS is still being used in UP Diliman as of this
writing, and has greatly boosted the efficiency of the registration procedures
through the streamlining of many previously tedious processes. It has
tremendously enhanced the experience of the CRS users through convenient
and user friendly modules. Aside from the very useful enhancements that
were introduced in the Blue CRS, the team extended the coverage of CRS
beyond registration and record-keeping to include many other
essential operations and transactions which now became a complex
interconnection of many different information subsystems within the
University.