Lecture
Это окончание невероятной информации про web-приложения.
...
to
preserve the ability to let "good" requests through and effectively block "bad" ones.
When a WAF is deployed in monitoring mode, it operates on the same principle as
an intrusion detection system (IDS). In this mode the WAF is used only to analyze
activity and issue warnings about violations. A WAF is usually deployed in this mode
even if you plan to use the request blocking capability. This makes it possible
to tune the WAF and better understand how the web application functions before
you move on to attempting to block requests. The advantage of this mode is
the ability to observe a wide range of potential attacks without worrying that false
positives will lead to inappropriate blocking. The disadvantages of this mode include
the fact that your staff will spend more time dealing with incidents that arise and
false positives, and also that "bad" traffic will be blocked with a greater delay.
In blocking mode the WAF will stop connections by dropping them (in proxy mode) or by
sending TCP reset packets (if installed off to the side). After a connection is reset, the WAF may
block an IP temporarily or permanently in order to prevent repeated attacks. Blocking mode
is most effective when there is a known vulnerability in your
application but the update that fixes it is not yet ready.
When a vulnerability is found in your application, you can create a specific rule in the WAF to
block attacks that exploit it. This protects your application from attacks while
you fix the application code or wait for the software vendor to release a patch.
This strategy protects the application quite effectively, preserving
its functionality and improving performance, but it will work only if
you have well-established processes for identifying and analyzing vulnerabilities.
Given all of the above, it is worth noting that information security professionals' attitude toward WAFs
remains ambiguous. Although WAFs are very effective against
known threats, they are much less effective against new threats and do not always handle
suspicious requests adequately. Some WAF-class products solve this problem
through tighter integration with vulnerability assessment tools. Regardless of the mode
in which the WAF is used and how effectively the policies are configured, you must remember that you will
need additional investment in this area.
Monitoring
Monitoring is mainly intended to track how real users use the web application,
and also to identify non-standard requests that may turn out to be
"bad". The principal value of monitoring is the ability to learn those features
of the application that you are not familiar with – this is important not only for the correct use of the
WAF, but also for the overall security strategy of the application. Although a WAF does provide a certain
degree of control, there are three additional ways of monitoring web applications, each of which
provides a new perspective on application activity:
• Network monitoring. Monitoring of network activity between users and the web server. This category includes WAFs, intrusion detection systems, packet
analyzers and other external tools. General network security tools and
other sniffing tools can capture all network traffic, but they have
little compatibility and cannot single out the specific packets
of a web application from the overall traffic. Simply viewing traffic is not enough to understand what
users are trying to do in the application – interpretation is required. If a solution
can analyze the specific traffic of web applications and is capable of
auditing network activity, we call such a solution Web Application Monitoring (WAM
– web application monitoring). Network monitoring is easy to integrate, since it does not
require any changes to the application, and it can only observe the outgoing and
incoming traffic of the application. This can be useful for detecting traditional attacks on the
application stack, but it is much less useful when traffic is correlated with higher-level
operations.
• Application auditing and log collection. Collection and analysis of logs and of the internal activity of the application.
Both in-house and third-party applications most often have capabilities
for internal auditing and log collection, but they all differ in the collection principle,
the way events are described and the record format. Even so, you may still not get a full
picture of what is happening in the application, since you are limited only to the data
that programmers added to the logging mechanism. For large and
widespread enterprise applications such as SAP, we have already seen third-party
tools that make it possible to add monitoring to them or mechanisms for interpreting
internal logs. General logging tools and SIEM can also be used
to collect and interpret events (with certain limitations) of web application activity, provided that event logs are generated.
• Database Activity Monitoring (DAM). DAM uses
various methods to record events related to database access and to generate
alerts when policies are violated. By monitoring activity between the web application and the database (or inside it), DAM can provide a more precise
examination and use of data, and also provide additional information
about interactions within the system during multi-step transactions in business processes. Some DAM products have plugins for major types of applications (for example, SAP
and PeopleSoft) to interpret database events as application activity events.
Given the active interaction of the vast majority of web applications with databases,
this approach to monitoring is quite effective for tracking
activity and finding violations of security policies.
A WAF can be used for monitoring, but specialized tools provide
more capabilities for controlling activity and make it possible to detect flaws and violations
that are not obvious from HTTP traffic monitoring alone. The focus of WAM is
on data sources, their analysis, activity logging and the generation of alerts about
suspicious events, whereas a WAF is oriented more toward detecting and blocking
already known attacks. There are significant differences between WAF and WAM in areas such as
activity storage, aggregation of data from various sources and its analysis, and therefore
the choice of the best solution depends on specific requirements. It is also worth noting that
web application monitoring solutions can still hardly be called mature – most of them are
at an early stage of evolution.
WAF + Vulnerability Assessment
Some vendors have already begun to offer hybrid solutions that combine
the functionality of vulnerability assessment products and a WAF. As mentioned earlier, one of the
difficulties of temporarily blocking particular vulnerabilities with a WAF is
identifying the vulnerability and creating a signature to block it. By combining assessment tools
with a WAF, we can automate the process of creating and applying new policies when
a new vulnerability is identified. Such a model implies identifying the vulnerability and instantly
passing the data to the WAF so that it can block particular capabilities.
In this section we will try to bring together all the parts concerning web application security
and produce a kind of guide that will allow you to develop a security system
suited to your organization. Web application security is not a case where there is
a universal recipe. Risks, size and complexity of applications differ for everyone, as do
the security awareness of users and employees, and most importantly,
each organization has its own goals for using web applications.
To give some practical recommendations, we have to approach the development of a
web application from the point of view of certain typical tasks. Therefore we have chosen three scenarios to
present the common web application security problems that
companies face, and we will examine each of them through the lens of a security system. We will discuss
the externally facing web applications of a large corporation,
the first application of a mid-sized company, and an organization larger than average
whose task is to secure an internal web application.
First we will describe the environment for each application, and then the overall strategy and
specific recommendations.
A large company with web applications oriented
toward interaction with external users.
In the first scenario we consider a large company with several web applications oriented toward
external users. They were developed to become a single
point of interaction with customers, employees and business partners. The primary
security drivers in this case are: fraud prevention, compliance with
regulatory requirements and fault tolerance to ensure the continuity of
business processes. Secondary drivers: protecting reputation, readiness for attacks, protecting
assets and data, and reducing maintenance costs. The main question here is not whether
security is needed, but by what means to achieve it. Most
enterprise applications have serious flaws in their code and, to be completely
honest, the main task in this scenario is to minimize the risks
posed by these flaws. No off-the-shelf product developed by third-party specialists
can magically solve all existing security problems, so
you need to invest not only in such products but also in improving your own development
processes, so that with each new release the applications get better from a security
standpoint.
Let us assume that our fictional large company has an existing security system,
a development team with some degree of maturity in understanding security issues,
but even in such a situation the question of solving the problems is not clear-cut. The company may already
have a security specialist on staff, but the development process has not yet built
processes for assessing security and identifying problems. A typical security specialist
most often proceeds from his experience of protecting networks, has no experience of secure development and
pays little attention to the code of web applications. We will assume that the security system
includes the use of vulnerability assessment tools, and they check the code for basic
attacks using SQL injection and buffer overflow attacks. Overall, security
is provided by a couple of third-party products and the efforts of a security specialist,
who points out security flaws that are fixed in future updates.
Recommendations
The strategy in this case comes down to the need to include security issues at the
development level, shifting the emphasis from external products to internal ones and to staff
training. Tools are selected and purchased to address specific deficiencies
in the skills of the development team and in organizational processes. A WAF is used
to provide security while updates that close the identified
vulnerabilities are being developed.
Training and process refinement. The area that will yield the greatest effect in terms of raising the
level of security is improving the knowledge and skills of the development team. The main
flaws noted by OWASP, as well as by other sources, point to problems that
can be solved by writing code properly and by testing... but only if
the development team knows what to do and how. Training helps developers
identify errors and problems in code and effectively reduces the number of flaws in each
subsequent development cycle. In developing staff, you can concentrate on raising the
skills of all developers rather than relying on one or two dedicated specialists
who will focus on security analysis.
A secure application development lifecycle. It must become one of the priority requirements
in application development, including specific requirements for code, review and
testing at the different stages of web application development. Otherwise, achieving
the proper level will be impossible, since all efforts will be thrown into finishing features
and functionality. Security must be part of the product specification and its requirements,
and each development phase must end with a check for compliance with these requirements
and conformity to the specification. This means that security tests during development
should be performed in the same way as testing before a release. Trained developers
are quite capable of providing code analysis and developing test scenarios for verification, but
additional tools for automating testing processes and verification tasks
are still necessary.
Legacy application code. There is a solution to the legacy code problem. One of the
serious problems is legacy code, which very likely has security
problems. There are several ways to solve this problem, but the main steps in
any case will be: 1) Identifying flaws and problems in the code (code scanning, vulnerability
assessment and penetration testing), 2) Prioritizing the fixes for the
identified flaws, 3) Planning the remediation of each vulnerability found.
Common methods of fixing vulnerabilities include: 1) Rewriting segments of code, 2)
encapsulation methods (for example, an interface), 3) Supplementing existing code by
creating procedures that verify paths/methods at run time, 4) temporary protection by
configuring WAF policies, 5) Moving SQL processes and checks into the database, and 6)
discontinuing the use of insecure functions. We recommend using static
or dynamic tools for the initial code check. These tools are
cost-effective, suitable for scanning large volumes of code and allow flaws to be identified
quite effectively. They detect and prioritize flaws,
avoiding the user errors that are inevitable in manual scanning.
Analysis tools also give staff some additional
knowledge about vulnerabilities, including examples in different languages. The resulting
findings about 16 thousand insecure IFRAME occurrences are, of course, no fun, but you will have to
accept and understand the problem before it can be solved.
External reviews. Periodic external reviews – vulnerability assessment,
penetration testing and source code review – are strongly recommended. Experienced, unbiased
specialists with experience in threat analysis can find flaws that were
missed during internal scans, and can also help teach developers
other attack vectors. Schedule external penetration testing once a quarter
or every six months – the knowledge and experience of good consultants go far beyond basic
threats, and therefore their work with the application will help uncover even non-obvious vulnerabilities
that could be exploited by attackers. We also recommend using
static analysis tools for internal code review as part of quality assurance
tests, and internal penetration testing immediately
before deployment – this will allow you to stress-test the application without fear of taking down
the production application. Major updates should also undergo external penetration testing
before they are installed.
Blocking. This is one of the areas whose necessity depends directly on the specifics of
your organization. In the case of an enterprise application, using a WAF is
a very important part of the security system. It provides basic protection and gives staff
the opportunity to deal calmly and without panic with vulnerabilities identified in the live
system. Of course, it is possible that the amount of code in your application is not very large and
there is no particular need for a WAF, but for large companies a WAF is not an option but a mandatory
part of the web application protection system. The development and update cycles of applications in such
companies are too long to provide a quick response to a newly found
vulnerability. We recommend using hybrid models that provide
WAF and vulnerability assessment functions, because such a combination makes it significantly easier
to develop and deploy new WAF policies. A WAF is not cheap, so we
cannot recommend its use to everyone. But still, this tool is the one that has
flexibility and makes it possible to fight not only existing but also future threats.
In general, we recommend that you take measures to raise the level of security in every
part of the application development and evolution process. Focusing on improving the
early stages of application development (requirements gathering, architecture, design) will bring the
greatest benefit from a security standpoint. For applications that are already
in operation, we recommend introducing external reviews and, if the budget allows,
using a WAF. Vulnerability assessment and penetration testing are of paramount
importance, regardless of whether the application is new or not, while a WAF is very important for a quick
response when a new vulnerability is identified. Considering that the risks of large enterprises are higher and
solving any problem is harder, it is important to understand that the investment in security must
be substantial as well. Security requirements, as well as changes to them, must be officially
documented for each stage of the application lifecycle – and compliance with these
requirements is verified at every significant stage.
A mid-sized company and PCI compliance
When we talk about web application security and about any requirements at all, it is worth
turning to the Payment Card Industry's Data Security Standard (PCI-DSS). In fact it is the only
standard that defines specific requirements for web application security. We
can, of course, grumble about the ambiguity of these requirements and ways to improve them, but we
cannot fail to admit that PCI is currently the main driver of
web application security today. Therefore, for the second scenario we took a
mid-sized company that needs to ensure that its web application complies with
the requirements of this standard.
The profile of our company is retail. Most of the profit is generated through
online sales. The commercial website is relatively new (less than 3 years old), and the development team
is fairly small and lacks sufficiently specific skills in information
security. That is, understanding the nuances of hacker attacks is not their strong suit.
PCI compliance is the main task, although it is clear that besides meeting the basic
requirements there is also a need for protection against certain types of attacks. On the positive side:
the amount of web application code is small and, since most of the profit is generated precisely
through the web application, management strongly supports initiatives to raise
the level of security.
In a nutshell, the PCI-DSS standard is a security standard for companies that process
payment card transactions as part of online commerce. In terms of security rules,
these are the clearest and most unambiguous requirements, including specific requirements for
security tools and for processes of handling payment card data. At the same time,
the standard also has a certain flexibility, expressed in the need to comply with the
spirit of the requirements. That is, even if your solutions differ from those recommended by PCI-DSS, but
they provide an appropriate level of security, they have the right to be approved. We
will concentrate on meeting the requirements set out in items 6.6 and 11.3, but will also
refer to section 10 and compensating controls.
Recommendations
Our strategy will focus on education and on changing development processes in order
to build security into the development cycle. Additionally, we suggest using a penetration testing
service, which will allow problem areas of the
web application to be identified faster. To begin with, focus on meeting the requirements, and only then
think about options for developing your protection in case the company grows. Do not be afraid to use
outside help for various tasks; this applies both to meeting PCI requirements and to
general application security matters.
Training, education and process improvement. Once again, we place the greatest emphasis
on education and training for staff, including project management. Despite
the fact that this requires a fairly substantial investment of time, it makes it possible to noticeably raise the
level of security and is economically effective (through improved
code quality, which reduces rework costs in the long run). Properly written code does not
need fixing later. In addition, the process of improving code will be continuous, which
will have a positive effect not only on security but on the quality of the application as a whole. In general,
if there is not much code, then education and training are the best path for a relatively
small company and will bring the maximum benefits.
External help. Make friends with an auditor or hire one as a consultant who
will help prepare for and carry out a PCI-DSS compliance review. An auditor will not just give
specific recommendations on individual PCI requirements, he will provide an expert assessment,
help interpret some ambiguous points, assist in developing a
strategy and save you from ill-considered and ineffective spending.
Section 11.3.2. 11.3 Penetration testing of the network and web application. In this scenario
we recommend external penetration testing – not only because it is a
requirement of the DSS standard, but also because an independent expert will examine your application from
a position as close as possible to that of a hacker. Moreover, in the future a limited budget
will surely force a choice between a WAF and code analysis under item 6.6, and penetration testing
will help you make the right choice. If code analysis is already being performed,
then it can be argued (perhaps without foundation) that it is a kind of compensating
measure that allows the requirements of this section to be met, but we still recommend
using penetration testing. External testing provides far more
than a list of specific vulnerabilities, also offering risk identification and detection of
suspicious application behavior.
Section 6.6. Our biggest debates concern the recommendation of using a WAF or
code analysis to satisfy the PCI requirements set out in section 6.6. In fact the standard
recommends using both, but it is widely known that this is quite expensive. Buying a
WAF is a quick way to satisfy the requirements of section 6.6, providing basic monitoring
and a basic platform for blocking attacks in the future. But the counterarguments to this option
enough – this includes the price already mentioned as well as the rather complex and painstaking work of
configuring policies. On the other hand, code analysis by a qualified security specialist
will help identify weak points in the application code and also help train
the development team by pointing out specific flaws. An external review makes it possible to quickly
assess the situation you are in and understand what you need to do in order to improve
it. The drawbacks of code analysis include the cost of the work, the time needed for
identifying and fixing the flaws, and, in addition, the constant changeability of the code, which
requires repeated reviews.
Even so, we recommend choosing a WAF. Bringing in a team of security professionals
for code analysis is, of course, an effective way to find flaws, but its value
is noticeably reduced, since periodic penetration tests provide largely similar data,
and the need to conduct them, as we remember, is reflected in section 11.3.2. In addition,
even with a relatively small or medium amount of code, the time needed to correct all
the flaws may turn out to be quite long, which would not allow you to pass the assessment for
compliance with PCI requirements within a fairly tight timeframe. Note that this
recommendation is valid only for this scenario. With different initial conditions, for
example, with more experienced staff and originally better code quality, we might
have taken a completely different path to achieve the required result.
Monitoring. Database activity monitoring (DAM) is a good choice for meeting
the requirements of section 10, which requires full monitoring of
access to payment card data. Web applications use a relational database for
storing payment card numbers, transactions, and other related data. DAM-class products
cover all network and console activity on the database platform and
provide targeted and cost-effective control at all levels of
access to credit card data. Consider this particular option, which will be good both
for auditors and for security specialists.
In our last scenario, we will consider an internal web application intended
for partners and employees within a medium or large business. Although this does not look like
a serious problem, even for a company with a staff of 100 people, an internal web application
can be a very critical point from the business point of view. Using data from workflow,
HR, accounting, sales, and other critical IT systems, these applications provide
effective support for the company's employees and partners. Given that almost all of the company's data is accessible from the web application, ensuring its confidentiality and integrity
is a very important task. The common opinion about protecting such systems most often
boils down to the idea that they are inside the perimeter and therefore not exposed to typical attacks,
but this opinion quite often leads to disaster. After all, if an attacker
gets past the outer barrier (or turns out to be an insider), the application will be practically
defenseless. That is, you should not rely solely on network security; you need to provide
at least a basic level of protection for the web application itself and access control.
Establish a baseline level of application protection, fix serious vulnerabilities, and make maximum
use of the benefits of education, training, and improvements to the code-writing process
in order to raise code quality.
Vulnerability assessment and penetration testing. Scanning web applications to
assess the level of security, check that updates are installed, and find configuration flaws
is the first of the recommended steps, and it will reveal the main vulnerabilities.
Security assessment tools are the most cost-effective way to
establish baseline security and bring it to an acceptable level. Penetration tests
can traditionally help assess potential risks and prioritize the
remediation of the vulnerabilities found.
Education, training, and process improvement. In this scenario these capabilities
will perhaps be even more relevant than in the others, if only because it is harder for a business to
justify investing in application security than in the case of external
applications.
Monitoring. Monitoring and detecting suspicious activity is an affordable yet effective
way to identify problems. We believe that a WAF would be too expensive a
solution in this case, and therefore we strongly recommend a more cost-effective way of collecting
and analyzing activity. Monitoring software that connects to the
web application can often be very effective and cost a quite reasonable amount, but
the burden of analyzing all the collected data will in this case fall on your development team.
Database activity monitoring can be effective for protecting critical information
in the back end, and it is a more sensible choice than a WAM.
Our recommendations are in fact quite specific and depend heavily on the characteristics of the
organization and the situation with its web applications. We chose the scenarios in order to
demonstrate the motivating factors in combination with the current security posture of the
web application and guidance on choosing tools, services, and changing internal
processes. But since applications support a significant number of business functions,
the process of raising the security level must proceed with the involvement and maximum
attention not only of technical staff but also of those responsible for business processes,
as well as the project manager. This will, without doubt, complicate the process, but moving forward should
happen only with the understanding and support of all stakeholders.
In any case, we must remember that security is part of the overall development process, and
our main recommendation for any scenario is to strive to ensure maximum
cost-effectiveness and to try to minimize the risks of failure or any deviation from
normal operation. It is also important to remember that the transformation of a web application will not happen
overnight. We cannot afford the luxury of halting all updates while
waiting for the moment when the development team fixes all the security flaws, and
therefore we should not forget that third-party products and services can provide invaluable help
in solving pressing problems.
Часть 1 Web Applications: Secure Development, Deployment and Use
Часть 2 Summing Up - Web Applications: Secure Development, Deployment and Use
Comments