Ask any information security manager or compliance officer and they’ll likely tell you that Web application security falls under the overall information risk umbrella. Along with network infrastructure security, endpoint security, physical security and so on; Web application security is a critical piece of the overall puzzle.

Looking at the big compliance regulations such as PCI DSS, HIPAA/HITECH and GLBA, they all cover information security best practices including:

• Policies
• Awareness and training
• Authentication
• Access controls
• System monitoring and activity review
• Incident response
• Disaster recovery

The same can goes for information security standards such as ISO/IEC 27002, NIST 800-53, etc.

Interestingly though, when it comes to Web application security, we often stop at the application-centric issues. We find and fix the SQL injection, cross-site scripting and other technical flaws and assume that’s all that’s needed for true Web application security. The reality is these other information security best practices – the non-sexy stuff like policies, audit logging and incident response – can be tied directly to Web application security.

Web application security shouldn’t stop prematurely with the technical issues. No business can afford to take that on. It’s up to us as IT, security and software development professionals to ensure Web application security is addressed at all levels.

Does your business have security policies?
If so, ensure your Web applications fall within their scope.

Do you use identity and access management processes and technologies?
If so, ensure your Web applications fall within their scope.

Does your business have security incident response and disaster recovery plans?
If so, ensure your Web applications fall within their scope.

Don’t manage information security risks in silos. That’s not a good long-term strategy. It’s not good for you, your business or anything related to what we do in IT.

Web applications are arguably one of the highest-risk components of any information security program and need to be handled accordingly. Make Web application security a big deal in your business…It is.

Improvements:

•  The accuracy of Script Checks has been increased. The Acunetix development team is dedicated to continuously improve scan detection of security checks.
• The Graphical User Interface (GUI) has been enhanced in order to make menu navigation and usage easier and more effective than ever before.
• SSL security audit script is launched automatically when scanning a HTTPS website, regardless if port scanning is enabled or not.
• Added a number of new SQL Injection variants checks.

Bug Fixes:

•  HPP detection security script failed when testing input scheme with excluded variants
•  Apply settings button not showing up in specific cases
• Fixed several issues related to pausing and resuming of crawler
• Fixed several issues when running multiple instances of the reporter
• Two backup files were being generated because of filename case insensitivity
• Filtering of wildcards from robots.txt

This release candidate of Acunetix Web Vulnerability Scanner Version 8 is considered complete, stable, and suitable for testing.

Testing Acunetix WVS Version 8 RC:
If you are interested in testing the Release Candidate build of Acunetix Web Vulnerability Scanner Version 8, and you already own an Acunetix WVS Enterprise or Consultant license with a valid maintenance agreement, contact us at beta@acunetix.com.

The Acunetix Web Vulnerability Scanner Version 8 Free edition can be downloaded from here.

Check out what’s new in Acunetix Web Vulnerability Scanner Version 8.

Let me explain why I didn’t validate everything. When you’re testing IP-based hosts, you often don’t need to manually validate every single finding – only occasionally. However, with Web applications, you need to validate just about everything to ensure you’re not documenting problems and solutions for issues that don’t even exist. I told the project manager that for an SSL certification flaw I uncovered, the scanner is providing the same information I’d be able to get via any other means. Ditto with a flaw that uncovered an outdated version of the server’s operating system.

Another flaw was regarding the internal IP address being exposed on the server. The project manager was specifically interested in that finding. I told him that the internal IP address uncovered was right before us in the scanner results. Although there may be some circumstances that warrant it, I’ve never found a need to manually validate this specific vulnerability. In fact, this one could be next to impossible unless you’re on the internal network, but that’s a different discussion. Either way, if the scanner finds an internal IP address, it finds an internal IP address. There’s no other explanation for how a scanner could come up with a random internal IP address that happens to match an internal IP addressing scheme (that I happened to know of) otherwise.

Be it a web vulnerability scanner or advanced penetration testing tools you use manually, you need reliable means to ferret out such information, especially if it’s to be reliable and accurate. But in most cases, based on my experience, you’re not going to have to double-check every single finding of a server host in this regard.

Keep in mind that not every flaw is the same. Some require true validation and some won’t even be found using automated tools. Testing for security vulnerabilities is as much of an art as it is a science and experience using the tools, knowing what to expect from them, deciphering their results and knowing what else to look for is critical. That still doesn’t mean we’ll find it all…there’s no way to guarantee that. As with radiologists and home inspectors, there are just too many variables and unknowns involved.

Regardless, Web application or IP-based host, if I, based on my knowledge and experience, believe something needs further manual analysis then I’ll do it. If not, I’ll leave it be and document it as such. Once you’re comfortable doing so, I recommend you do the same.

Interestingly, it ended up being that the client’s questions weren’t about whether or not I actually validated each and every finding, but rather whether or not the hosts I listed in the report were indeed affected. There’s a difference. Make sure you keep all of this in mind and everyone is on the same page as you move forward with your security testing. Proper scoping and advance planning are half the battle.

Look at any given physical security-related video or access control system and the technology is amazing. From high-definition to DVR storage to remote access, you can literally control your physical security systems from a simple Web browser or even a mobile app. The problem is these systems are getting lost in the information systems complexity present in the average enterprise. But they’re no different than any other Web-based system – the potential for Web related vulnerabilities is endless. All it takes is a rogue insider or, in certain cases, an external attacker to compromise the essence of your organization’s physical security.

There’s a bit of irony in it all.

When performing my information security assessments, any given video management or access control system is chock full of Web flaws such as cross-site scripting, cross-site request forgery and so on. There are also more general flaws such as default passwords, no SSL, no audit logging or alerts enabled – no nothing related to application security. To top it all off, these systems are rarely, if ever, patched. Typically a systems integrator installs the physical security systems with zero security in mind and the systems stay that way with no one monitoring them, no one maintaining them…there’s no accountability.

Anyone with ill intent has free reign to watch (and control) internal video cameras, cover their tracks by deleting logs and actual video files, setup backdoor accounts and so on – all the things that bad guys do.

Indeed, we have a long road ahead of us in securing physical security-related video and access control systems. I strongly believe that unless and until these systems are included in the scope of Web security testing, businesses, government agencies and everyone in between will continue to have these critical security flaws flying under the radar.

Like with any other computer system, if it has a URL or an IP address, it’s fair game for attack. Give these systems the attention they deserve.

Many of my clients use third-party managed firewalls and intrusion detection and are typically alerted to such attacks against FTP. Yet still, any login hacking attempt can make you nervous especially knowing that manual cracking is likely to fly under the radar of these controls. So the question becomes, is there anything you can do to be more proactive and prevent FTP password-cracking attempts from occurring in the first place?

The ultimate control is to remove FTP from public access but that’s often not a reasonable option. Managed firewall and IPS is another great option. Ditto with any in-house firewall/IPS you may have. Changing the default FTP ports can help prevent automated attacks. This will provide minimal value and may end up being more trouble than it’s worth but it’s an option nonetheless. Otherwise, the best you can do is ensure that complex passwords are in place and enforced and intruder lockout is enabled on the FTP server.

All of this starts with knowing how your Web/FTP servers are currently at risk. Running a simple port scan of your external-facing systems can uncover FTP that you may not have known about – or have forgotten about. I recommend going a step beyond that running a good vulnerability scanner of the host itself to see what FTP-centric flaws it uncovers. In the end, you’ve got to look at your Web servers from every angle. All it takes is one seemingly benign weakness to undermine everything you’ve worked so hard to harden and protect.

WVS 8 BETA 2 Change Log

The following updates have been included in the BETA 2 build of WVS 8:

Featured Improvements

• Additional .NET AcuSensor support for .NET versions 3, 3.5, 4
• Improved blind SQL injection timing tests for PostgreSQL
• Improved blind SQL injection timing tests for request-timeout situations
• Logs are now flushed to the log-file every 10 seconds when running in console mode
• Scheduler feature: notification bar appears if the connection with the server is lost

Bug Fixes

• Crash (runtime passive analysis) when “Disable Crawler Aerts” option is enabled
• Problem with logging of HTTP_Anomalies when running multiple instances
• Problem with writing to temp folder when running multiple instances
• Issue with saving application logs to an invalid folder when running the Scheduler
• Crash when multiple instances of WVS try to detect custom 404 error-page patterns
• Scan does not resume correctly when the Scheduler automatically resumes a scan
• Issue with retest functionality for web application scripts
• Proxy crash, commonly when the process is already executing
• Settings in use by another instance cannot be saved as a Scan Settings Template
• Reporter crash when the text in the alert details is too long
• Periodical vulnerability reports show incorrect publishing date
• Database ID allocation is now synchronized between multiple WVS instances
• Scan results cannot be download from the Scheduler since Internet Explorer 7 cache is not used
• HTML report format is missing from the Scheduler web interface
• Installer assigns full permissions to the license file (non-admin users receive an error when scanning)
• Fixed the Scheduler’s Add Scan dialog on Internet Explorer 9
• Errors related to a browser-tab do not appear if a different tab is being viewed
• Malfunction with some Advanced Penetration testing tools when used through a proxy server
• XSS tests are no longer case-sensitive
• Scheduler returns invalid error message when connecting to password-protected applications
• Scheduler not scanning password-protected applications
• Crash with AcuSensor for .NET
• False positives are saved for each user instead of globally
• Changes to application settings not synchronized across multiple instances
• Typos in UI
• Reporter RTF-export malfunction
• Reporter sets incorrect filename for exported and saved reports
• Text wrap working inconsistently across reports

Become a Beta tester

Are you a security researcher who’s passionate about website security? Do you want to stay current with the latest cutting-edge web security scanning technologies? Contact us at beta@acunetix.com to learn more. (Requests are subject to approval)

NOTE: Acunetix customers who already own an Enterprise or Consultant license with a valid maintenance agreement are automatically eligible to participate as beta testers.

The Acunetix WVS Version 8 user manual is available in PDF Format and also in HTML Format.

The major issue here is that selecting ineffective security testing tools can be a costly venture. I’ve burned thousands of dollars and countless hours on tools that seemed like a good fit based on their tricked out websites and fancy marketing slicks. But talk is cheap so buyer beware. You have to take these tools for a spin to see if they’re going to be a good fit based on YOUR style inside YOUR environment, and based on YOUR business needs.

Whether you’re doing the actual work or just want to make sure your IT and security staff members are using what’s best for the organization, the simple truth is that good security audit tools can and will make a difference. Always remember that there is no one best tool but if you’re smart about your approach you shouldn’t have to spend a lot of money to get the job done right. If you invest a relatively small amount time researching, asking prospective vendors tough questions and actually trying the tools before you buy them, then you can’t lose.

When you choose and use good tools, you’ll know it. Amazingly, you’ll minimize your time and effort installing them, running your tests, reporting your results – everything from start to finish. Most importantly, with a good web vulnerability scanner you’ll be able to maximize the number of legitimate vulnerabilities discovered to help reduce the risks associated with your information systems. At the end of the day and over the long haul, this will add up to considerable business value you can’t afford to overlook.

So what’s the ideal setup for intruder lockout? Well, every situation is different and every business has its own unique needs. That said, I often recommend locking accounts for certain period of time (i.e. 5-10 minutes) after 5-10 failed login attempts. You may also use some form of automated password reset logic in conjunction with this process. Even something like tarpitting failed login attempts (i.e. purposefully slowing them down) can be beneficial as long as the delay is reasonable or the accounts are eventually locked.

Enabling intruder lockout is a relatively simple fix given what’s at stake. Whether you’ve got basic HTTP, forms, or some type of multi-factor authentication, keeping track of login abuse can have great payoffs — especially given the bad choices people make regarding passwords. Granted, intruder lockout could have the reverse effect on security. If you’ve got an attacker with a set of legitimate user accounts (often email addresses which can be relatively easy to obtain), then he could conceivably attack accounts via login pages that have intruder lockout enabled and effectively create a denial of service situation. You’ve got to determine what the greater risk is – password cracking or potential denial of service.

In many situations, intruder lockout on web login pages can eliminate a considerable amount of risk – especially in situations where you offer a SaaS/cloud solution and you’re not at liberty to control the enforcement of certain things like password complexity. Do what you can to set your users up for success. Even if they choose to use weak passwords, intruder lockout will at least help minimize the risk of successful password cracking.

You can watch a high quality version of this video on YouTube.

Many of you have been biting their nails in anticipation of this Beta, so sit tight and read on for the next most important stage in the evolution of Acunetix WVS.  Version 8 of Web Vulnerability Scanner has been optimized to make life easier at every stage of a security scan. WVS is easier to use for web admins and security analysts alike: enhanced automation, ability to save scan settings as a template to avoid reconfiguration, and multiple instance support for simultaneous scans of several websites. WVS 8 also ushers in a new exciting co-operation between Acunetix and Imperva: developers of the industry’s leading Web Application Firewall.

If you are interested in testing the new BETA of Version 8, and you already own an Acunetix WVS Enterprise or Consultant license with a valid maintenance agreement, contact us today at beta@acunetix.com.

The FREE version of Acunetix WVS 8 BETA can be downloaded from here

New to WVS 8

Manipulation of inputs from URLs

Acunetix WVS can automatically detect URL parameters and manipulate them to detect vulnerabilities. This technology is not present in any other competing vulnerability scanner.

Automatic IIS 7  rewrite rule interpretation

Using the web application’s web.config file, WVS 8 can automatically interpret rewrite rules without requiring any manual input.

Support for custom HTTP headers

To function correctly, some web applications need incoming requests to contain specific HTTP headers. It is now possible to define custom HTTP headers to be used during automated scans.

Imperva Web Application Firewall integration

An exciting co-operation between Imperva and Acunetix: WVS 8 scan results can be automatically imported into an Imperva Web Application Firewall and interpreted as rules.

New vulnerability class: HTTP Parameter Pollution

At the time of writing, Acunetix WVS 8 is the only scanner that tests for this security vulnerability.

Multiple instance support

Acunetix WVS 8 can be relaunched as multiple instances on the same machine, allowing the user to scan multiple websites and opening up further support for multi-user scenarios on the same server/workstation.

Redesigned Scheduler

Accessible via a web interface, the new Scheduler allows administrators to download scan results from any workstation, laptop, or smartphone. The new Scheduler will automatically launch another instance of WVS when multiple web scans are due, preventing multiple processes from depending on the resources of one WVS instance and thereby allowing scans to complete in less time.

Automatic custom 404 error page recognition and detection

Acunetix WVS 8 can automatically determine if a custom error page is in use and recognizes it without requiring any custom 404 recognition patterns to be configured for a scan

Scan settings templates

WVS 8 now allow the settings for the scan of a specific application to be saved as individual templates, making it quick and easy to recall the exact settings for a website each time it is scanned. This is particularly useful when scanning multiple sites, allowing the user to load the template for each site instead of re-configuring all the settings manually.

Simplified Scan Wizard

In addition to the introduction of Scan Settings Templates and automatic custom 404 error page recognition, the Scan Wizard contains far less options so it’s much easier and quicker to kick off a scan.

Smart memory management

The following settings have been added to ensure even the most complex scans will complete automatically, and successfully:

• Define number of files per directory
• Limit number of subdirectories per website
• Assign Crawler memory limit

Real-time Crawler status

Crawler data is now updated in real-time information and provides live feedback how many files have been crawled, how many inputs have been detected, and more.

Scan termination status included in report

Reports now include the termination or completion status of each vulnerability scan. For example: the report will display if the scan was completed successfully or halted manually.

Web application coverage report

A new report template that lists all the web application files crawled and specific vulnerability tests performed on each file.

Log file retention

It is now possible to define the retention span before log files are automatically flushed; to ensure logs are not deleted each time WVS is restarted.

Significant WVS 8 improvement 

Improved web security check scripts

• All security check scripts have been optimized to reduce false positives even further
• The scanner checks for the latest variants of vulnerability classes like XSS, SQL injection, and more.

Become a Beta tester

Are you a security researcher who’s passionate about web security? Do you want to stay current with the latest cutting-edge web security scanning technologies? Contact us at beta@acunetix.com to learn more. (Requests are subject to approval)

Acunetix customers who already own an Enterprise or Consultant license with a valid maintenance agreement are automatically eligible to participate as beta testers.

The Acunetix WVS Version 8 user manual is available in PDF Format and also in HTML Format.

Subject matter

• Jerod Brennen: This presentation will provide insight into the Social Media Audit/Assurance Program issued by ISACA from a practitioner’s perspective. Auditors will gain insight into social media programs from an operational perspective to bridge the gap between implementation and audit. Attendees will learn: What they should audit in a social media program, how to introduce social media auditing to the organization, and resources for staying current in social media security trends.
• Rob Barnes: The evolution of software to a service (SaaS) delivery model frees users from the limitations of traditional infrastructure such as scalability, performance bottlenecks, and capacity. But these are raditional infrastructure such as scalability, performance bottlenecks, and capacity. Data breaches and audit failures can occur just as easily within the cloud as within traditional computing infrastructures.
•  Angie Singer Keating: Attendees will be introduced to the fundamentals of IRP and will learn how to craft and implement an incident response planning program which relies on processes and documentation. A special emphasis will be placed on the requirements, responsibility, processes and procedures needed to provide a rapid and reliable incident response capability.
•  Tim Maloney: IT Governance has become a focus area for both IT and Web Security Audit organizations. Recent research shows that IT organizations see IT governance activities as areas “needing improvement” in their organizations. Similarly, Internal Audit departments are increasingly being asked to assess the strategic performance of IT and to consider the appropriateness of the IT organization‟s response to new and emerging risk areas.
• Don Shepherd: This presentation will focus on: The Encryption/Masking of sensitive data, Separation of duty (How to control when and where a DBA can use elevated privileges, providing fine grained access control for DBAs), and Audit/Monitoring activity (Database activity monitoring, know what happens and when inside your database.)

Event details

Location:
Four Points Sheraton
Pittsburgh North
910 Sheraton Drive
Mars, PA 16046
(724) 776-6900
Registration – 7:15 a.m.
Session – 8:00 – 4:1

Cost:
ISACA Member – Free
Non-Member – $30
Students – $10

Registratio deadline:
November 30, 201

Do the victims just say: “Well, management decided that it was just our marketing site that didn’t have anything the bad guys would want so we decided not to test it for security flaws…”?

Perhaps they could go on to say: “We understand that such a breach makes us look unprofessional and come across like we don’t take our IT or the reputation of our business very seriously. And we know a simple and relatively inexpensive web security scanner could’ve uncovered the flaw that led to this situation, but we just couldn’t make the business case for it…”?

Seriously, folks?

Shame on the marketers and hosting providers as well for not doing even the most rudimentary web application security testing. As I’ve written in the past, I don’t recommend relying on vulnerability scans alone, but they’re certainly a very good start!

Ignoring this glaringly obvious elephant in the room is just inexcusable. I know, that’s easy for me to say being on this side of the equation. But not being able to justify even a simple scan of your marketing site using free or inexpensive tools that anyone with any level of computer experience can run? I don’t get it.

If you’re reading this blog, this is probably a non-issue. Just make sure you’re scoping your ongoing assessments to look at your marketing site and any associated content management system at least once or twice a year. You may be surprised what turns up. Beyond that, we can all work together and encourage other business owners, friends and family members who aren’t IT savvy to test for the low-hanging fruit – even on their marketing sites. We’ll all benefit in the long term.

Users don’t appreciate the business reasons behind the policies
Simply telling people what they cannot do is like telling a four year old to stop playing with her food. You have to explain the reasons why policies exist and why it’s everyone’s job to adhere to them. In certain cases users aren’t even aware that certain policies exist, so without adequate training one can’t expect users to follow a set of rules to which I haven’t been initiated.

Users don’t buy into the policies
Even if you’ve laid out good reasons for your policies to exist, users may still disagree. They may not see the point of such nonsense, especially when they have the perception that they know what’s best.

Users know the policies won’t be enforced
Like speed limit and seat belt laws, people know that they’ll be able to get away with policy violations because there’s no possible way for IT and information staff to possibly monitor for and catch everything. Network complexity contributes to this problem and users are often correct – policies are indeed often suggestions with no real teeth. That still doesn’t mean you shouldn’t have the proper technologies in place to actually enforce your policies. You won’t catch everything but at least you can set your users up for success by using technology to your advantage where possible and reasonable.

Users are lazy
The ‘Must have it now!’ human desire for instant gratification is very powerful. People don’t want to take the time to do things right nor have the desire to jump through a bunch of hoops getting in their way of doing their jobs. The offending attitude is “maybe I’ll adhere to it like I’m supposed to next time…”

Users’ desire to violate policies outweighs their perception of the risks involved
Building on the laziness factor, users haven’t really thought about the consequences of their choices or assume that one bad decision every now and then won’t hurt. This mentality can spell disaster for the business. It’s up to you to convey why their risky behavior is bad for everyone.

Like the Art of War concept of “knowing your enemy”, understanding the basis for security policy violations is extremely important if you’re going to do something about it and (finally) fill the gap that’s too often overlooked in business today. Continuing to ignore the problem – or assuming that it’s a “management issue” will only prolong your web security woes.

Looking at this new vulnerability scan report, it became clear we were comparing apples to oranges. First off, this third-party used a more limited scan policy. Ironically, the policy I used tested for everything yet found fewer issues. Your scan policy choice alone can dramatically impact the outcome of your web security audit. But that’s not all that can impact the results of your tests. A few more considerations I shared with my client were:

• What’s being looked at: the actual production application or an ad-hoc test environment? The other scan was against this third-party’s unique production system that’s part of a multi-tenanted cloud application. I had looked at a lab environment setup specifically for my assessment which had zero customization. A follow-up assessment of their production environment found nothing new. The key difference here was not the application environment itself (although that could’ve made a difference). Instead it was the customization of the application that’s taking place for each customer.
• What credentials were used for the third-party test? What’s different about those user permissions compared to what I was given?
• How was the application’s security policy configured during the third-party scan? How is that different than what I looked at?
• The third-party’s Web vulnerability scanner version was several weeks newer than what I originally used. New builds, new vulnerability checks and updated policies had since come out.

Some additional things that can affect what’s uncovered are your scanner’s crawler depth and timeout settings, HTTP request handling, parameter exclusions and even firewall or IPS controls that affect production differently than a test environment. It may seem like a no-brainer and it probably should be but once you start throwing in all of these variables you may very well get different results.

Moving forward you can dig down further and uncover the not-so-obvious gotchas. Just be careful because certain (often many) scanner findings are false positives or don’t really matter in the grand scheme of things in the context of your business. As I advised my client, unless this third-party is manually validating every single finding, a person running a vulnerability scanner is not nearly as detailed a test as what’s involved in a more in-depth web application assessment so be careful what you commit to fixing.

The important thing is to ensure you’re looking at all possible areas of your applications from all possible angles and doing so on a periodic and consistent basis. You’re not going to get it figured out the first scan, or maybe even your fiftieth scan. Just strive to tweak your environment (be it production or test) and customize your scanner to provide greatest insight so you can find the most vulnerabilities in the shortest period of time.

http://www.globalteksecurity.com/

Following are the highlights of the event, as well as the decades of experience in security technology covered by the conference’s lecturers:

• Resilience: convergence of security, IT governance and business continuity
• Computing in the cloud: considerations and concerns about the new risks
• Sensitive information focused on the gateway. Depth, analysis, content, and context
• Risk analysis and information classification
• Virtualized environments: the new challenge for IT security professionals
• Government security: the contribution IT security to business success
• SAAS: Security As A Service — The pros and cons
• Logs & Management: is correlation of events better in the cloud?
• … and lots more!

So if IT security and technology is your passion, and you’re in Bogotá on the 26^th of October, then this event is one you surely can’t afford to miss.

Once a user is infected, the malicious code can do a variety of things. It can change the color scheme of the page the user is viewing. It can do more nasty things such as replacing images with pornographic content. Using the same techniques, links on the page may be re-written to point to malicious locations. Sometimes clicks can also be forced, simulating user action without his knowledge. Another popular XSS attack reads out the user’s cookie and transmits it to the hacker. This allows him to impersonate the user and hijack his session. If the user happens to be the system administrator, the hacker can take over the entire website.

In this video tutorial I demonstrate what an XSS attack is to show you how a hacker can use XSS vulnerabilities to hack into your website. I start the video by explaining the mechanisms of cross site scripting, and I proceed to demonstrate a number of pranks you can play on unsuspecting users. I also demonstrate how cookies can be stolen to hijack sessions and I take a peek into the vulnerable code that allows such attacks. I hope that this video will both entertaining and educational, and that by learning about XSS you can keep your own website safer.

How can you do this? You need to prove that you’re thoughtful and careful about money and that the decisions you’re making regarding Web security are in the best interests of the business. You can be frugal and show management that you’re willing and able to cut back, deal with what you’ve got and find ways to make things work better that may have been overlooked the past. For example, one thing I see quite often is network administrators and security managers not taking advantage of Web security controls they already have at their disposal, such as:

• URL sanitizers and input filters built into Web server platform(s)
• Event logging, monitoring and alerting capabilities built into server operating systems
• Web application firewall capabilities built into traditional perimeter firewalls
• Identity and access management controls embedded directly into the Web applications

When it comes to tightening our belts and improving Web security we have to get creative. I’ve learned this in my motorsports hobby. Like so many others believe, my earlier inclination was to spend a ton of money adding more horsepower to my car so I could lower my lap times. I soon learned that spending money on the issue wasn’t the solution.

Instead, I started focusing on what I already had on my car and, most importantly, in my mind. I soon realized that my car wasn’t the problem but rather my lack of hand-foot-eye coordination and the barriers I had in my head of what a car should be capable of doing. By focusing inward, in less than a year I had drastically lowered my lap times to levels equivalent to spending thousands of dollars on more horsepower. It was hard work but I didn’t have to spend a dime in order to get a whole lot better.

Think about all the areas where you can improve Web security in and around your business. From existing technologies to business process tweaks to your people and even your own skillset. There’s likely a lot of room for growth. The great thing is, if you take the initiative and make things happen, you won’t have to ask management for a single dollar.

New features

• The Client Script Analyzer engine now supports jquery + jquery UI + YUI library
• New URL Rewrite option; Match full URI. If this option is enabled, a URL rewrite rule can be matched against the whole URI and not just path

Improvement

• Major improvements in AcuSensor Technology for PHP

Bug fix

• Fixed: Login Sequence Recorder not using Proxy settings specified in WVS settings

How to upgrade to build 20111005:

On starting up Acunetix Web Vulnerability Scanner, a pop up window will automatically notify you that a more recent build is available for download.  To download the latest build, navigate to General > Program Updates node in the Tools explorer, and click on Download and Install new build.

Click here for the complete Acunetix WVS change log.

Contact us on support@acunetix.com for any technical queries, and on sales@acunetix.com for any sales queries.

Business leaders have learned that they must teach, train and develop their employees. Otherwise, they can’t expect people to perform at their highest levels. The same goes for us working in and around IT and Web application security. We can try to be high and mighty telling people the sky is falling because our Web applications aren’t secure. We can tell people all day – every day – that they can’t do this, that or the other – all in the name of Web security. But we have to be realistic and ask: how’s that working for us?

Skipping formal teaching, training, and development, and instead forcing Web security on other people doesn’t work all that well. It’s like trying force a religion or political ideology on others and expecting them to just say “Okay, whatever you say.” People and politics just don’t work that way. In fact, many people couldn’t care less about Web application security. Just because something is important to us doesn’t mean it is (or has to be) important to everyone else. Combine the forced messages with ego – something most of us working in IT have struggled with (and need to get over) – and you’ve got a recipe for application security mediocrity.

Rather than spouting no, no, no in a one-way binary fashion without any explanation of where we’re coming from, we need to outline why we’re saying what we’re saying. Why we’re recommending that we need to tighten down on application security controls. Why we’re recommending we spend money on making the development lifecycle better. Why application security matters to the business as a whole.

It’s like continually telling a child not to do something. It just doesn’t work long term. We have to explain why.

We must communicate the value of application security. This means showing that gaining control and visibility into our Web environments is better than the alternative. It also means demonstrating – where it’s reasonable – how Web application security can serve as a competitive differentiator and most definitely impacts the bottom line. But it’s not going to happen unless and until we help push the message forward clearly and respectfully and show its value in the context of our businesses. We’re often Web application security’s worst enemy and we need to come up with ways to fix that.

Back in the dot-com era of 1998-99, you may recall that Internet security was all about firewalls and SSL. Interesting (and sadly), that’s still the case in so many situations. The mantra is lock down the perimeter and everything will be fine. It’s an interesting study in human psychology. Like seatbelts, cigarettes and poor diet, the elephant is in the room; yet so many people choose to ignore the consequences. Ditto with SQL injection. We know what’s hurting us yet we don’t do anything about it. Case in point, the 2011 Ponemon Institute State of Web Application Security survey found that 69% of organizations rely on firewalls to secure web applications. I’m not surprised based on what I see in my work, but wow! Not much has changed in nearly a decade and a half.

Just in the past year, we’ve seen numerous high-profile SQL injection attacks against businesses such as Barracuda Networks, Expedia and HBGary. If it’s happening to these businesses, we can only imagine how bad the SQL injection problem is with smaller or less risk-savvy organizations!

Interestingly, I just completed a Web security assessment of an application that used to have SQL injection. The issue was originally fixed but has since returned. Talk about regression at its worst. Granted, authentication in to the application was required to access the vulnerable pages but the problem is still there for exploitation by a malicious user or an attacker who has stolen someone else’s login credentials. Making the problem more complex was the fact that SQL injection only existed when logged-in with certain user roles. SQL injection wasn’t exploitable at every level simply because the pages weren’t accessible to those users.

Let this be a reminder that SQL injection is out there. It’s in your in-house applications as well as in your commercial off the shelf and cloud applications. And sensitive data is there for the taking. Traditional security controls like firewalls, SSL, passwords and the like aren’t going to help. You have to step back and look at the bigger picture. Are you performing the right tests? Are you checking all possible user role levels to see which users have access to what? Are you checking back periodically to make sure old flaws haven’t returned or new ones haven’t surface? Are you developers on board? Are you asking the right questions of your vendors? You’ll never really know unless and until you dig in deeper.

Alive with the energy of the ICT sector and the buzz of real business, GITEX Technology Week — held at the Dubai International Convention and Exhibition Centre (DICEC) — is the gateway to one of the world’s fastest emerging and investment ready ICT markets: the Middle East.

GITEX delivers a leading platform for industry innovation and an impressive track record of attracting the biggest names in the IT sector, connecting over 3,500 domestic and international IT vendors with more than 136,000 ICT professionals. As the largest IT exhibition in the Middle East, GITEX Technology Week is a buzz of business activity for the entire ICT industry. Dedicated sectors include: business solutions, GITEX card technology, consumer technology, mobile apps and content, and many more…

You can find Comguard — and Acunetix — at the following GITEX stalls:

Comguard @ GITEX Exhibition :Hall 1 ,F1-30
Comguard @ GITEX Shopper: West Hall,WL3-5

Register and win!

Comguard are giving their subscribers the chance to win a notebook computer. Simply register on Comguard’s website to get yourself into the draw.

This time the president was lucky; the hackers were ethical and reported the exploit before publicly disclosing it. The Barack Obama website administrators took over a week to respond, but eventually patched their system with some help from the researchers. This is the white hat world where hackers follow a procedure called Responsible Disclosure. They report the exploit to the web site and wait for a fix before announcing their discovery. However there is also a dark side – an underworld of cyber-criminals who exploit website vulnerabilities for financial or political gain.

Below is the original report timeline, at the time of writing I did not have a confirmed date of the Patch, however the researchers told me that the website is not vulnerable anymore.

Report-Timeline:
================
2011-08-30: Vendor Notification
2011-09-19: Vendor Response/Feedback
2011-09-**: Vendor Fix/Patch
2011-09-12: Public or Non-Public Disclosure

Image from last year's hack against the same website

Many times XSS vulnerabilities are used to deface websites. This type of activity is the equivalent of throwing paint on a billboard on the highway. It’s easy to do and ugly for the website, however the damage is easily reversed.

This particular exploit appears to be more sophisticated than simple vandalism. Vulnerability-Lab succeeded in injecting Javascript into the back-end of the website. This Javascript, made it all the way into mailshots generated by the system. In their Proof of Concept (PoC) code the researchers demonstrated how an IFRAME exploit could be inserted into emails sent from info@barackobama.com.

This email comes from info@barackobama.com and contains a malicious script.

The screenshot above shows a page from the Global Evolution Security website as it appears embedded in an email sent from the barackobama.com website. The email source is below:

Check out this video from the President’s lunch to hear him speak=20
in his own words about what it means to organize. Then will you=20
sign up to be a volunteer for 2012 in >”<iframe =
src=3Dhttp://vulnerability-lab.com width=3D800 height=3D800>?

The attackers managed to inject this by exploiting a vulnerability in the volunteer signup form that is available on the website.

Volunteer Signup

During the signup process, the user is asked for his name, email address and other details. This form allowed them to inject the script tags that made the attack possible. Apart from appearing in emails, the attack script also appeared on other parts of the website, meaning that visitors to the barackobama.com web page were also vulnerable.

XSS attacks are often overshadowed by their ugly cousin – SQL Injection. This causes them to remain undetected for a long time. SQL Injection attacks do a lot of damage and are much more frequent, however here we see once again that XSS can be used effectively with devastating effects.

To circumvent these types of attacks it is important to run automated vulnerability scans using a Web Vulnerability Scanner. Vulnerability scanning should be followed by thorough code reviews and patches must be applied where necessary.

New security check

• Security checks for Apache httpd remote denial of service

Improvements

• Firefox plugin now supports Firefox v.6
• Inclusion of more variables discovered by Acusensor during a scan

Bug fixes

• Fixed HTTP verb tampering security checks with further reduction of false positives
• Paths edited in HTTP Authentication settings node are being saved correctly
• Actions menu is appearing correctly in the Small Business Edition

How to upgrade to build 20110823:

On starting up Acunetix WVS, a pop up window will automatically notify you that a more recent build is available for download.  To download the latest build, navigate to General > Program Updates node in the Tools explorer, and click on Download and Install new build.

Click here for the complete Acunetix WVS change log.

Contact us on support@acunetix.com for any technical queries, and on sales@acunetix.com for any sales queries.

http://dsteamseguridad.com/hackxcolombia/

Following is a preview of the exciting and interesting activities held at this year’s HackXColombia event:
 
 

Conferences

• Spray-JIT-SU: Implications for interpreted languages ​​in Web environments
• Python hacking
• Practical Attacks on Web applications using pre-designed virtual machines
• Architecture and Punishment of denial of service attacks distributed in Colombia

Workshops and Seminars

• Practical Hacking in 5 phases
• Intrusions and Audit ARMITAGE Metasploit
• Making SSH, Apache and Tomcat safer

Speakers

• David Mora (Master Engineer)
• Juan David López (Master Engineer)
• Ricardo Yepes (Engineer)
• Manuel Enrique Gonzalez Ramirez (Engineer)
• Esteban López Peláez (Engineer)

For all Colombian security enthusiasts, or anyone who happens to be in Colombia around the 8^th of October, this is an event that shouldn’t be missed. The complete event schedule is also available online.

On Thursday morning a post appeared on the popular Full Disclosure Internet discussion group listing XSS vulnerabilities in no less than 20 high profile websites. Amongst the vulnerable are McDonalds, IEEE Explore, Harvard University, and energy.gov. The vulnerabilities were discovered by a hacker who goes by the handle *Invectus*.

Is an XSS Vulnerability a big deal?

XSS vulnerabilities (Cross-Site Scripting vulnerabilities) are often overshadowed by their big cousin, the infamous SQL Injection. This does not make them any less effective or deadly. XSS and SQL Injection attacks are similar in the way they inject malicious code. The difference is that an SQL attack, injects code into the target database whereas an XSS attack injects code into the target browser. In an XSS attack the hacker uses your website to inject code into your visitor’s browser.

Once a user is infected, the malicious code can do a variety of things. It can change the color scheme of the page the user is viewing. It can do more nasty things such as replacing images with pornographic content. Using the same techniques, links on the page may be re-written to point to malicious locations. Sometimes clicks can also be forced, simulating user action without his knowledge. Another popoular XSS attack reads out the user’s cookie and transmits it to the hacker. This allows him to impersonate the user and hijack his session. If the user happens to be the system administrator, the hacker can take over the entire website.

How to: XSS McDonalds

Below is the entire list of websites that were disclosed as vulnerable. At first glance the list is long and cryptic, but with some basic hacker techniques we can soon make some sense out of them.

http://video.state.gov/en/search/img-srchttp-i55tin
ypiccom-witu7dpng-height650-width1000/Ij48aW1nIHNyY
z0iaHR0cDovL2k1NS50aW55cGljLmNvbS93aXR1N2QucG5nIiBo
ZWlnaHQ9IjY1MCIgd2lkdGg9IjEwMDAiPg%3D%3D

http://www.telegraph.co.uk/search/?queryText=%22%3E

%3Cimg%20src=%22http://i55.tinypic.com/witu7d.png%2
2%20height=%22650%22%20width=%221000%22%3E

http://www.dsm.com/en_US/cworld/public/home/pages/s

earchResults.jsp?search-site=%22%3E%3Cimg+src%3D%22
http%3A%2F%2Fi55.tinypic.com%2Fwitu7d.png%22+height
%3D%22650%22+width%3D%221000%22%3E&noMimimumKeyword
s=false

http://www.schools.nsw.edu.au/psearch/ext/?refine=n

ew&QueryText=%22%3E%3Cimg+src%3D%22http%3A%2F%2Fi55
.tinypic.com%2Fwitu7d.png%22+height%3D%22650%22+wid
th%3D%221000%22%3E&Go.x=29&Go.y=25&Go=submit

http://thetablet.co.uk/search.php?q=%22%3E%3Cimg%20

src=%22http://i55.tinypic.com/witu7d.png%22%20heigh
t=%22650%22%20width=%221000%22%3E

http://www.scstatehouse.gov/cgi-bin/query.exe?firs

t=FIRST&querytext=&category=%22%3E%3Cimg%20src=%22

http://i55.tinypic.com/witu7d.png%22%20height=%226

50%22%20width=%221000%22%3E

http://www.highered.tafensw.edu.au/vsearch/tafehig

heredu/?QueryText=%22%3E%3Cimg%20src=%22http://i55
.tinypic.com/witu7d.png%22%20height=%22650%22%20wi
dth=%221000%22%3E

http://www.mcdonalds.com/content/us/en/search/sear

ch_results.html?queryText=%22%3E%3Cimg%20src=%22ht
tp://i55.tinypic.com/witu7d.png%22%20height=%22650
%22%20width=%221000%22%3E

http://www.watersportholland.nl/cgi-bin/watersport

holland/zoeken.cgi?search=Vera&query=%22%3E%3Cimg+
src%3D%22http%3A%2F%2Fi55.tinypic.com%2Fwitu7d.png
%22+height%3D%22650%22+width%3D%221000%22%3E

http://www.gpo.gov/fdsys/search/searchresults.acti

on?st=%22%3E%3Cimg%20src=%22http://i55.tinypic.com
/witu7d.png%22%20height=%22650%22%20width=%221000%
22%3E

http://www.networkcomputing.com/sitesearch?sort=pu

blishDate+desc&queryText=%22%3E%3Cimg+src%3D%22htt
p%3A%2F%2Fi55.tinypic.com%2Fwitu7d.png%22+height%3
D%22650%22+width%3D%221000%22%3E

http://www.unc.edu/search/index.htm?q=%22%3E%3Cimg

+src%3D%22http%3A%2F%2Fi55.tinypic.com%2Fwitu7d.pn
g%22+height%3D%22650%22+width%3D%221000%22%3E&cx=0
14532668884084418890%3Ajyc_iub1byy&cof=FORID%3A10&
ie=UTF-8&hq=inurl%3Adevnet.unc.edu

http://cugir.mannlib.cornell.edu/search?querytext=

%22%3E%3Cimg%20src=%22http://i55.tinypic.com/witu7
d.png%22%20height=%22650%22%20width=%221000%22%3E

http://ieeexplore.ieee.org./search/freesearchresul

t.jsp?newsearch=true&queryText=.QT.%3E%3Cimg+src.E
Q..QT.http%3A%2F%2Fi55.tinypic.com%2Fwitu7d.png.QT
.+height.EQ..QT.650.QT.+width.EQ..QT.1000.QT.%3E&x
=58&y=13

http://vivo-vis.cns.iu.edu/vivo1/search?querytext=

%22%3E%3Cimg+src%3D%22http%3A%2F%2Fi55.tinypic.com
%2Fwitu7d.png%22+height%3D%22650%22+width%3D%22100
0%22%3E

http://google.nyu.edu/search?site=NYUWeb_Main&clie

nt=NYUWeb_Main&output=xml_no_dtd&proxyreload=1&pro
xystylesheet=stern_frontend&sitesearch=www.stern.n
yu.edu&q=%22%3E%3Cimg+src%3D%22http%3A%2F%2Fi55.ti
nypic.com%2Fwitu7d.png%22+height%3D%22650%22+width
%3D%221000%22%3E&x=8&y=6

http://ofa.fas.harvard.edu/cal/search.php?q=%22%3E

%3Cimg%20src=%22http://i55.tinypic.com/witu7d.png%
22%20height=%22650%22%20width=%221000%22%3E

http://www.uidaho.edu/search?q=%22%3E%3Cscript%3EI

nvectus%3C/script%3E&cof=FORID:9&cref=http://www.u
idaho.edu/search?xml=1&ticks=634508915004972966

https://vivo.ufl.edu/search?flag1=1&querytext=%22%

3E%3Cimg+src%3D%22http%3A%2F%2Fi55.tinypic.com%2Fw
itu7d.png%22+height%3D%22650%22+width%3D%221000%22
%3E

http://energy.gov/search/site/%22%3E%3Cimg%20src%3

D%22http%3A//i55.tinypic.com/witu7d.png%22%20heigh
t%3D%22650%22%20width%3D%221000%22%3E

 

Understanding XSS

I will take the www.mcdonalds.com vulnerability to help explain XSS in more detail.

The raw XSS attack is repeated below:

http://www.mcdonalds.com/content/us/en/search/search_results.html?queryText=%22%3E%3Cimg%20src=%22http://i55.tiny

pic.com/witu7d.png%22%20height=%22650%22%20width=%221000%22%3E

The first thing we will do is seperate the URL from the query. We split at the first question mark (?) and get two parts:

1. URL Part:

http://www.mcdonalds.com/content/us/en/search/search_results.html

2. Query Part

queryText=%22%3E%3Cimg%20src=%22http://i55.tinypic.com/witu7d.png%22%20

height=%22650%22%20width=%221000%22%3E

The URL part identifies the vulnerable file on the server. In this case the vulnerabilitie lies within the search functionality of the site, a very common attack vector for both SQL Injections and XSS attacks.

The Query Part is the actual attack code. You will notice lots of % symbols. These are called URL Encoders and are difficult to read without the right tools. I use the Acunetix HTTP Editor tool that is bundled with Acunetix WVS to decode URL Endoded Query Parts.

The human-readable Query Part now looks like this:

queryText=”><img src=”http://i55.tinypic.com/witu7d.png” height=”650″ width=”1000″>

This script is hardly malicious. It injects the image of a flag into the McDonalds web page. I tested it out assuming that McDonalds would have fixed this security flaw immediately, and I was surprised to find that the vulnerabilitiy is still there.

This attack is pretty innoctuous as it is, however a crafty hacker will most likely manage to inject other malicious, such as the code below, which displays the user’s cookie:

<IMG SRC=javascript:alert(‘You cookie is this:’ + document.cookie)>

I decided to check other websites to see if they patched their sites after the disclosure was announced. You find my results in the next sections.

Winners and Losers

I categorised the orignial list into the Winners – those who fixed the vulnerabilitiy within 24 hours of it’s diclosure, and the Losers – those who left the secuirty flaw there for everyone to exploit. Within the next few days hackers will be having a field day with the Losers especially those like IEEE Explore who serve paid content from their site.

Winners – Vulnerability is fixed:

• Harvard University
• US Department of State
• Energy.gov
• The Telegraph UK
• University of North Carolina
• Cornell University
• University of Idaho

Losers – Website is still vulnerable:

• McDonalds

• US Government Printing Office

• IEEE Explore

• DSM

• South California Legislature

• Networkcomputing.com

• VIVO

• NYU Stern

• The Tablet UK

• NSW Public Schools

How to be a Winner

It is very probable that the hacker used automated tools to scan these web sites and automatically discover vulnerabilities. The injection code for each page is slightly different so the hacker must have tweaked around with each site to make his injection successful.

If you want to stay one step ahead you will need to use similar tools that the hacker uses. The most common one is a Web Vulnerability Scanner that supports automatic XSS detection. You will need to scan your website periodically to ensure that updates to the site do not expose new flaws.

Final Thoughts

In this case our hacker single handedly defaced 20 big web sites using XSS. The companies were lucky because the hacker did not have any malicious intent other than exposing them. The danger is what will come next; now that this list is in the wild the black-hats of the hacker community will pounce at every exposed vulnerability that is not patched.

If your website is on the list above you’d better do something about it now. If you want to make sure that your site never appears on such a list make regular scans and code reviews to fix any XSS vulnerabilities you may find.

We’ve all experienced this scenario in some capacity. And we’ve seen what can happen. Security suffers, data breaches occur, executives get bent out of shape and perhaps some heads roll. In a classic case of saving face, the stakeholders in management predictably ask “How in the world did this happen!?” and will often go on to proclaim “We can’t let this happen again!” The cycle continues…

But you know what’s interesting? I’m not seeing this scenario as much these days. Instead of time to market holding back Web application security, it’s now cost. Always an underlying consideration, cost is now at the forefront of IT and application security. It’s driving virtually everything in business today. That’s fine. I understand the need to pick and choose where money goes. The problem is that it’s not going to security the way it needs to be.

Case in point: I just had a conversation with an acquaintance who’s a solutions architect at a Fortune 500 company. After telling him what I do for a living he sort of smirked and said “Yeah, we need to be heading towards better application security but instead we’re going in reverse.” He validated the very thing I’ve been seeing of late by telling me that it used to be that time to market was the excuse for poorly-written code but now it’s cost. He said plain and simple, that management just doesn’t want to spend the money that needs to be spent on application security.

Saying the cost is too high to spend money on application security highlights two core problems:

1. IT professionals not doing enough to educate management on what’s at risk what there is to lose in the context of their unique business
2. Management choosing to ignore the realities that we’re all facing with application security today

Seeing how quickly businesses are going in the opposite direction with security in the software lifecycle begs the question: when will the right time come to spend money on security?  How many breaches? How many lawsuits? If application security were any other key business function, it’d get the visibility and attention it deserves. Management just doesn’t see it that way.

If you step back and look at this problem, it’s a chicken and egg situation. The mindset of “If we only had money to spend on application security, we could be more secure.” is like saying “If only that fire would put out some heat we’d throw some logs on it”. As with any capital investment or operational expenditure, application security is a choice. The money is there, it’s all in how it’s being spent. Cost is the current management excuse for not spending money on the testing, training and other things required for solid and secure software. It’s up to us in IT, information security and software development to change that.

http://www.govware.sg/index.html

This is the 20^th GovernmentWare seminar and exhibition, this year focusing on the importance of adopting a forward-looking IT security posture to mitigate increasingly sophisticated and pervasive cyber-attacks. It underscores the need for a security conscious mind-set in dealing with today’s ever-changing and unpredictable cyber threat landscape. With the right security mind-set, there will be a need to re-examine current efforts, re-assess the present state of readiness, and re-iterate on the need for collaboration as we embark on this inevitable and uncertain journey.

The importance of Govware is a simple yet crucial one. Govware has been known to be one of the most respected IT security events that is held in Singapore. In its humble beginning, Govware was catered to only government related industries but it has since grown to an astonishing size. This growth has led to it being a prolonged to the 3 day event it is today, with the first day only open to government related sectors and the second and last day opened to the public. Endorsements and justification of products from different government bodies have also instilled confidence in the public sector as well as promote brand recognition.

Come down to stands B07 and B09, Ace-Pacific and Acunetix are looking forward to seeing you at an event that is not to be missed!

There’s no way the Acunetix Facebook iPad competition was going to fly under the radar. As soon as August was out we immediately began receiving messages asking who the competition winner was. Well, the security world is a busy one and we’ve cheekily decided to leave you toasting for a while longer just to raise a bit of suspense, but the moment has finally arrived.

So, without further ado, the winner of the June 2011 Acunetix Facebook iPad competition is:

>>> Antonio Carlos Scola <<<

Congratulations to Antonio from the Acunetix team. We hope this shiny new iPad 2 will increase your productivity with its many cutting edge business utilities, and allow you to keep updated with all our latest blog posts and announcements. We’ll be in touch with you shortly to finalize the details on redeeming your prize.

Things to come

A big thank you to all who participated by following, commenting, and liking our Facebook posts. Let me assure you that more competitions will come your way, including a super-secret lucky draw from all those who actively contribute brilliant, insightful, knowledgeable, inspiring comments on our Facebook page. So keep yourself active and get your friends to follow us too.

Next time, it could be you!

Getting the attention of your employees and having them on your side can go a long way towards improving the security of your Web sites and applications. When people who are otherwise disconnected from IT get on board with security, they’ll often go out of their way to ensure they do what’s right. I’ve also seen employees go the extra mile to help people in IT and software development when they find security flaws in the systems they’re working on. Employees don’t want security to get in their way but they’re often willing to step out of their traditional roles and help contribute to Web security to make things better for the business.

On the other hand, if you do things with security that irritate your employees they’ll often do just the opposite by making your life miserable and putting your business at risk. Everyone loses.

Focus on the positive and you’ll reap what you sow. Here are some ways I’ve found to get employees on your side and minimize business risks:

1. Make sure employees are in the know and completely understand what you’re trying to accomplish with Web security. Properly set expectations and priorities are half the battle.
2. Establish and build trust. This means leading by example to help influence your organization’s culture and show your users that you’re a person of value who’s not out to get them.
3. Ensure that employees who come up with ways to help prevent or minimize the effects of security breaches are properly acknowledged and rewarded.
4. Help management create ways to integrate IT and security user awareness training participation (and results) with employee reviews.

These are things you as an IT or security professional can get started on today. I wouldn’t try to go it alone though. You really need management on board and ideally have a security committee consisting of representatives from HR, legal, operations, internal audit, IT, information security and physical security. A functional and well-run committee can help tremendously with visibility and accountability and improve overall Web security way beyond what you could otherwise do by yourself.

Employees are everything to the business. View them as allies rather than the enemy. Once you get them on your side, you’ll build your credibility and everyone will surely benefit.

• Innovative AcuSensor technology
• Web server configuration detection
• Web server security scan (Port Scanner) against services such as DNS, SSH etc
• Dictionary (brute force) attacker to test password strength of login pages or HTTP authentication
• Report Generator to create professional and regulatory compliance reports specifying detected vulnerabilities and suggested fixes
• Vulnerability Editor to create custom exploit attacks or modify existing ones
• Support for all major web technologies like JavaScript, AJAX, ASP, ASP.NET, PHP, Ruby, JRun and CGI
• Scanning profiles to tailor specific vulnerability checks for separate websites
• Scan comparison tool to easily spot differences and locate new vulnarabilities between previous and recent scans
• Easily re-launch scans on modified areas of a website
• Automatic Custom error page detection
• Discovery of directories with weak permissions
• Includes advanced manual penetration testing tools liek the HTTP Editor, HTTP Fuzzer, HTTP Sniffer and more.

View the complete FAQ