One of Jacadis' longest standing partners is Qualys. Qualys produces a vulnerability management suite that helps our customers manage vulnerabilities, measure compliance and maintain security.
Qualys also publishes a set of free tools for the public to use.
You can check your web site with FreeScan.
With your FreeScan, you can run scans to detect security threats:
Network perimeter vulnerabilities
Web application vulnerabilities
Malware hosted on your website
We recommend and some regulatory or contractural obligations may require regular site scanning. Scanning regularly for vulnerabilites and malware is part of a best practice security program.
We find that many customers that come to us after a breach through their web properties built their web sites without thinking about security requirements. The sites were released into production without a security test. The sites were on the net for years without proper attention to their security needs.
Does that sound like your web properties?
Are you aware of the how secure your web properties are?
Jacadis' own Jerod Brennen on panel for ISACA e-Symposium,'Protecting your Enterprise with Comprehensive Application Security' will start at 8:00am PDT / 11:00am EDT / 4:00pm BST.
Please go to http://isaca.brighttalk.com/ click on the enter event button on your screen to launch the live event. If you hear music, the event hasn't started yet.
If you are not logged in already, you will be prompted to input your username and password under the 'Profile' area and hit submit.
Conference Speakers & Topics:
Ted Julian, Chief Marketing Officer,Co3 Systems speaking on "When Application Security Fails: Data Loss Incident Management Best Practices"
Jerod Brennen, Principal Security Consultant,Jacadis speaking on "Application Security 101 - Back to the Basics"
Steve Hunt, Senior Manager,Crowe Horwath LLP speaking on "Application Controls: An Internal Auditor's Perspective"
Mike O. Villegas, Director of Information Security,Newegg speaking on "Advanced Web Application Security Techniques"
Closing Comments by Aleese Eckenrode, Education Coordinator,ISACA
We had a unique call come in yesterday, one I wish we had more of, but we don't.
A small business owner with a brokerage of sorts wanted to develop a website that would allow the producers and the buyers to post information, in some cases highly personal information, review non-confidential subsets of the data about the other and keep the whole thing secured from the outside.
She asked if we could help and provide "small business pricing quotes."
In fact, I don't think many security firms get those calls.
Most of our calls are after the fact either after the app or system has been developed or just after it has been breached.
She called us asking questions because she didn't have any answers. I think that approach serves us well in many endeavors.
We can help her. We offered to help her develop a list of functions and safeguards she needed in her application, help her manage the procurement process and then to test the application for security before she accepted it from her developer.
In 10 years of business that was a first.
Most web applications, particularly web applications are built with out much thought to information security, customer privacy or regulations covering the information.
Truthfully no application is 100% secure. But an application that has been designed and developed with careful consideration for its information security, user privacy and regulatory requirements stands a great defensive chance once it has been launched. Testing that application before launch further raises the defensive posture. Regular testing and a proper operational routine after it has been released to production even further raises that posture.
Again, our experience has been that most businesses, particularly small business, design and develop applications, release them to production and then through some event realize that security is a concern. There is a breach or a break-in. The site is knocked off line by a denial of service attack and revenue streams are interrupted. The invoice from the payment card processor is higher than they want to pay and they find it is because of non-compliance with PCI. And so on.
This occurs because two things don’t happen up front:
Security just isn’t talked about as part of the deisgn process. It must be!
An assumption is made that developer and hosting providers on the project will handle security. In most cases they won’t unless you demand it of them and back the demand up with contracts and tests.
Here is a list of non-technical questions you need to consider as part of your design conversation. Getting technical on some of these issues may require a member of your IT staff or an outside consultant. But any small business owner should be able to answer these questions if they are trying to build a business using technology:
What is the sensitivity of the data on our planned site? Is it regulated data?
Who regulates the information or audience that uses our site? What are your obligations to protect it? What are your obligations to maintain user privacy? Does your privacy policy match that obligation? Will the site be developed with the guidance of a privacy policy?
How long can the site be offline before it negatively impacts our business? When will customers usually visit the site to transact business? If we are off line an hour of peak traffic time how much revenue will we lose? Profit?
What do our customer’s expect from us in regard to protecting their privacy?
Will you have user forums or accounts on the site? How will you verify those signed up are really customers? Or really people?! Does that matter? Will you allow any and all comments in your forums? Do you need to edit them or block them?
How does the developer ensure the web application is secure? The database?
How does the hosting provider help secure your application? How will you know they are doing their job?
You then need to make sure that your development partner builds the site to meet the requirements these questions should raise to the surface.
That site must be deployed in a technical environment that is at minimum protected by:
Proper and verified operating system and application hardening procedures
Separation of the development (where you’ll continue to create and innovate as well as test) and production
We then recommend you test the site against your requirements to make sure they were met (best to do that before that last check goes to the developer!). We also suggest you conduct a vulnerability scan against the site to make sure that it wasn’t developed with technical weaknesses a hacker could use to create havoc for you.
And then finally we recommend that you, as a matter of routine, continue running those tests to make sure the sight maintains the secure posture you paid for in the first place.
Does your application security plan take into account the OWASP Top 10 Web Application Security Risks?
Since 2004, organizations have steadily adopted the OWASP (Open Web Application Security Project) standard as a way to evaluate not only their own applications, but also those designed by third parties. While many developers and security professional are familiar with the OWASP Top 10, most do not understand the mechanics of the vulnerabilities and how to prevent them. If your firm develops customer facing web applications or uses internally facing web applications that collect or process protected information OWASP's practices are a concept your technical teams should adopt.
By popular request, Jacadis is offering a two-hour, instructor-led interactive class designed to introduce developers, designers, architects, managers, and organizations to the OWASP Top 10, and to educate them about the consequences of the most important web application security weaknesses. This class is taught by certified security consultants that routinely perform PCI, HIPAA, and OWASP penetration tests and vulnerability assessments.
Secure Application Development – Best Practices - OWASP Top 10 March 31, 2011 @ Tech Columbus 11:00 am — 1:30 pm - Lunch will be provided
The Federal Trade Commission (FTC) announced yesterday Twitter's settlement against charges that Twitter "deceived consumers and put their privacy at risk by failing to safeguard their personal information."
In a non-technical pedestrian manner David Vladeck, Director of the FTC’s Bureau of Consumer Protection boils it down in this quote on the FTC site:
“When a company promises consumers that their personal information is secure, it must live up to that promise. Likewise, a company that allows consumers to designate their information as private must use reasonable security to uphold such designations."
Twitter was hacked twice, once in January, 2009 and again that same year in April. And during that time period Twitter's privacy policy stated that:
"Twitter is very concerned about safeguarding the confidentiality of your personally identifiable information. We employ administrative, physical, and electronic measures designed to protect your information from unauthorized access.”
Twitter had borrowed some of the language from another firm's privacy statement (how did your privacy statement get written?).
The FTC acted under Section 5 of the FTC Act which gives them the power to hold firms accountable for "unfair and deceptive" practices. The deception here is that Twitter publicly proclaimed it did something that in fact it did not do.
There were no monetary fines levied. According to legal friends of mine this is due to the fact that Section 5 of the FTC Act does not grant the FTC the power to levy fines or penalties.
Again, according to the FTC:
"...Twitter was vulnerable to these attacks because it failed to prevent unauthorized administrative control of its system, including reasonable steps to:
require employees to use hard-to-guess administrative passwords that they did not use for other programs, websites, or networks;
prohibit employees from storing administrative passwords in plain text within their personal e-mail accounts;
suspend or disable administrative passwords after a reasonable number of unsuccessful login attempts;
provide an administrative login webpage that is made known only to authorized persons and is separate from the login page for users;
enforce periodic changes of administrative passwords, for example, by setting them to expire every 90 days;
restrict access to administrative controls to employees whose jobs required it; and
impose other reasonable restrictions on administrative access, such as by restricting access to specified IP addresses.
Under the terms of the settlement, Twitter will be barred for 20 years from misleading consumers about the extent to which it protects the security, privacy, and confidentiality of nonpublic consumer information, including the measures it takes to prevent unauthorized access to nonpublic information and honor the privacy choices made by consumers. The company also must establish and maintain a comprehensive information security program, which will be assessed by an independent auditor every other year for 10 years."
Again, according to my legal friends that means that Twitter is now in a spot that should they fail to fulfill their part of the settlement the FTC may find them in contempt of the settlement which then would permit the FTC to levy fines and penalties.
There is plenty of debate in the security blogosphere discussing whether or not the FTC "went too far" or was legislating by regulation.
For me the important element of the case is the lesson for other growing and emerging businesses.
Twitter has grown more rapidly than they could have known when they started up. As the subscriber based sky rocketed, however, the start up culture that is more feature focused than formal process focused carried onward. One of the hacks was because a dictionary word, easily guessed, was used to protect an executives Google Applications account. A dictionary-based password can be guessed easily especially if you know the person who owns it. Strong passwords are the foundation of information security. If a company isn't using strong passwords we question their commitment to security. Ultimately that lack of commitment is what got them.
Here are some lessons to consider:
Start security and privacy planning with business and application planning and design from the beginning. That is particularly true if your key processes involve confidential, consumer or protected information. The cost of doing security later will be much higher because you'll have to re-engineer. Metaphorically it is similar to adding a basement after your house is built.
Likewise, include information security, privacy and trust considerations in your culture early on. Technology, difficult and expensive to re-engineer, is easy in comparison to restructuring a company's culture. You can operate securely and create a loose modern team oriented culture. Focus on the customer trust issue as a rallying point rather than the constraints you feel security places on you.
Plan for your future value from the get go. Twitter's apparent laissez faire attitude toward information security and privacy earned them a 20 year dance with the FTC. It also puts a mark of toxicity on their value. If I had the money laying around to purchase Twitter would the potential of an historical lapse in security or the potential for one in the future, either of which would spawn a contempt finding and financial penalties, give me pause or give me leverage to reduce my offering price? Understand now how a breach or poorly architecture might impact your future value and work with that in mind.
Don't cut and paste privacy statements or other statements of values or customer trust from other sites and call them your own. Get an attorney or a privacy professional or both engaged in your developing your privacy policy. That policy is a sign of trust for your customer now. But poorly executed it could be a weapon used against you in the future. And as you work on developing that policy remember it is a legal and technical document and not a marketing brochure.
Finally, don't say things you don't mean or that you can't back up. Be honest. That should be true in all your business dealings as a start up or emerging firm. Customers purchase trust.
Have you built security into your culture and technology from the start? Working on it now?
There's been much buzz about the hacked AT&T application that exposed 140,000 iPad early adopter emails. In the end it was sloppy coding practices. How well are your businesses coding practices? Is your application secure?
According to New York-based Praetorian Security Group, which obtained a copy of the PHP script used to scrape e-mail addresses from AT&T's servers, the attack succeeded because the mobile carrier used poorly designed software.
A nine-person hacking group known as Goatse Security claimed responsibility for the script, which amassed 114,000 e'-mail addresses.
"There's no hack, no infiltration, and no breach, just a really poorly-designed Web application that returns e-mail address when ICC-ID is passed to it," Praetorian said in a late Wednesday entry on its security blog.
Implications for you:
If you are building a business idea in part on an idea that is being implemented as software you have to consider security as part of the feature set. Early on feature and function take precedence. The sooner you consider information security as part of the feature set and development process the lower the cost of securing later. If your business is successful (and who starts one NOT to be successful) at some point consumer, customer or regulator is going to expect you to have secured that application and the information in it.
The lesson for the innovator, entrepreneur or growing tech company executive is that sloppy design and poor coding practices can expose you. You have to ask yourself "If we had information taken from our application would it impact us negatively?"
If you answer yes you might want to ask your developers and yourselves the following questions (preferred answer in parentheses following if it is a simple yes/no):
What information is collected, processed and stored in the application? What regulatory, contractual, ethical or legal obligations do you have to protect it?
What has been done to consider security in the planning and design of the application?
Was security considered a feature? (YES)
Has security been included in the application as a default? (YES)
What has been done to identify and consider the threats (think bad guys and their techniques) most likely to be encountered while the app is in production?
What has been done to reduce the attack surface of the application and its infrastructure?
Are application accounts set up with the principle of least privilege? (YES)
Is the application protected using a principle of defense in depth? (YES)
When the application fails does it fail securely? (YES) When it fails does it fail with the door open or closed (securely)?
Does the application trust unverified third party code sets? (NO) Third party processes and processors? (NO) If yes, is there an active administrative process to verify their security? (YES)
Are key administrative aspects of the application separated in their duties? (YES)
Does security depend on security by obscurity? (NO)
Is security in the application complex or simple? It should be simple.
Is security tested as part of the development life cycle? (YES) in prerelease? (YES) regularly in production? (YES)
Don't like the answers you are getting? Explore more at OWASP. And then take action to remove sloppy insecure planning, design and coding from your business.
Don't simply rely on your webmaster or an administrator to fill the survey in. Use it as a chance to discuss your online privacy practices. Do you do what you say you will do? Real trust can only be built by your being transparent about your practices. If you are collecting information on customers but don't want to admit to it are you operating in a way that builds consumer trust?
If you are building a new web based business use the survey to guide a discussion with your developer. Only collect information that you need to serve the customer best. If you aren't going to use it, don't collect it!
If you have an existing web facility use the survey to guide a discussion of your current practices. Are you collecting information that isn't used? Why? If you aren't using it but collecting it you are either exposing yourself if you aren't properly protecting it or spending money to protect something that you don't need in the first place!
Jacadis presenting lunch & learn on web application security with Platform Lab in Columbus
I wanted highlight an upcoming lunch and learn reviewing web application security that might be of benefit to you if your business develops and deploys web applications. The event is free and lunch will be provided. Please register below, and send this on to individuals in your organization who would benefit.
Jacadis, the company I work for, is putting the lunch and learn on with its non-profit partner the Platform Lab, part of Tech Columbus.
Presenter: Simon Herring, CISSP – Founder and CTO Jacadis, LLC.
Cost: Free
When: September 16th, 2009 11:00 am — 1:00 pm - Lunch will be provided
Cyber thieves use automated scanners to find web security holes… Why don’t you?
Thousands of web applications have been developed by companies of every size and industry to support business growth, extend customer interactivity, and lower service delivery costs. But how deliberate are you in evaluating the security of web applications throughout the application’s lifecycle, from inception to retirement?
Consider the following:
Many web vulnerabilities exist due to limited knowledge of secure coding principles. Catching these weaknesses before “go-live” can decreases costs related to post-deployment patching and the risks associate with a security break-in.
The sophistication of web hackers and data thieves continues to increase. Just scanning during the development cycle assumes no new web application exploit techniques will be developed and shared in the Black Hat community. The “10 foot wall” you created last Fall won’t be able to withstand the “11 foot ladder” that cyber thieves throw-up this Summer.
In addition to being an established best practice for protecting general web servers, routine web application scanning can help you comply with federal, state, and industry regulations. With little marketing effort, you can also build security into your brand and show your existing or potential clients that protecting sensitive data is important.
The tools and processes are available to prevent the deployment of poorly coded and insecure web applications. Perhaps you know the risks, but you don’t know how to manage them, or where to begin. To answer these questions, we are hosting “Securing Web Applications using Acunetix WVS” to demonstrate how Acunetix Web Vulnerability Scanner (WVS) is an effective tool to add to your security routine.
In this edJACADIS seminar, we will:
Examine the components of a successful web application development process
Discuss the role of web application vulnerability scanning in the overall security process
Explore how Acunetix Web Vulnerability Scanner (WVS) can be used by developers and security analysts alike, to perform automated or manual web vulnerability testing.
Sitting at a break in the action Campus Technology 09 thinking.
Comparing conference chatter from last year to this .. the pace of innovation has been rapid if the talk of all things 2.0 is any indication. Just about anyone will quickly engage and share how they are using social networking or web 2.0 technologies in the classroom, in their business, in research and innovation projects or just in life. But ask a question about security or privacy and it is obvious that the dive into the 2.0 pool hasn't included some basic thinking about security.
Innovation without security thinking simply sets the stage for bad things to happen in the future. Too many security practioners lament the social network. But stopping it is like trying to stop water from flowing downhill. The trick is diverting it, channelling it, guiding it to go where you want it to go.
Embrace these new technologies. As an entreprenuer I've already seen payoffs from being socially networked. But embrace them thoughtfully with intentional security.
I am gearing up for a trip to Boston next week to participate in Campus Technology '09, the 16th Annual Education Technology Conference. In the midst of all this buzz about Web 2.0, the conference Mastering Digital Worlds: Web 2.0 and beyond, will be an introduction to how colleges and universities of all sizes are investing and applying these new technologies to the learning environment. Hopefully, these schools are doing this securely. We'll find out while we are there.
The excitement around the Web 2.0 "revolution" feels just as exhilerating as the excitement around the Web 1.0 "revolution". We have some young guns in the company who have put on a brave face as I "entertain" them with my war stories from my days introducing businesses to the original web. But this new interconnectedness has the opportunity to both distract and enrich our lives. I look forward to learning at the conference.
And as always I'll have my eyes and ears open looking for examples of innovations that have been implemented with proper attention to information security principles and the privacy requirements of the audience. From my perspective an innovator at a higher education institution and an entrepreneur growing a business have similar issues to overcome.
We'll be exhibiting in Booth 630 in the main exhibit hall at the Boston Convention and Exhibition Center.
Here's a bit of information on our participation in the show last year:
Qualys (Photo credit: Wikipedia)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=ebee6eb3-830c-4783-900a-2602abcf8880)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=21bf0f4e-5079-40a6-8fa0-469a47fb9b3c)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=ccfe62ad-3373-46a7-ac5c-98eecdeb878d)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=ff9b1370-2f97-4320-abd9-4080ccef4296)
