Saturday, February 9, 2008

How To: Secure Your Developer Workstation
Improving Web Application Security: Threats and Countermeasures
Summary: This How To helps you improve your development workstation security. Developers often have computers running software such as IIS, Microsoft SQL Server, or the Microsoft SQL Server Desktop Engine (MSDE.) For example, Microsoft Visual Studio® .NET is designed for local development with IIS, so it is common for a developer to run IIS locally. As a developer, you need to be able to secure these services against attack, even if your computer is in a protected local area network.
This How To provides quick tips to help you improve the security of your developer workstation, along with tips about how to keep it secure. It also helps you avoid common problems that you are likely to encounter when you secure your workstation. Finally, it provides tips about how to determine problems and to revert security settings if they prove too restrictive.
Note This How To is not exhaustive, but it highlights many of the key issues.
Before You Begin
Before you begin securing your workstation, you need the following tools:
• Microsoft Baseline Security Analyzer (MBSA). Microsoft provides the MBSA tool to help analyze the security configuration of your computers and to identify missing patches and updates. You can download the MBSA tool from http://www.microsoft.com/technet/security/tools/mbsahome.mspx.
• IISLockdown. The IISLockdown tool reduces your computer's attack surface by hardening default IIS and Windows configuration settings and by removing unnecessary IIS extensions. IISLockown also installs the "404.dll" ISAPI filter, which is used to report "404 File Not Found" messages when disabled extensions are requested.
You can download the IISLockdown tool from http://download.microsoft.com/download/iis50/Utility/2.1/NT45XP/EN-US/iislockd.exe.
• URLScan. URLScan is an ISAPI filter that rejects or allows HTTP requests based on a configurable set of rules. It is integrated with IISLockdown, although you can also download it separately. It comes with customizable templates for each supported server role.
To install URLScan without IISLockdown, see Microsoft Knowledge Base article 307608, "INFO: Availability of URLScan Version 2.5 Security Tool," at http://support.microsoft.com/default.aspx?scid=kb;en-us;307608, in the Microsoft Knowledge Base.
Steps to Secure Your Developer Workstation
To secure your developer workstation, perform the following tasks:
• Run using a least privileged account
• Patch and update
• Secure IIS
• Secure SQL Server and MSDE
• Evaluate your configuration categories
• Stay secure
Run Using a Least-Privileged Account
You should develop applications using a non administrator account. Doing so is important primarily to limit the exposure of the logged on user and to help you to design more secure software. For example, if you design, develop, and test an application while you are interactively logged in as an administrator, you are much more likely to end up with software that requires administrative privileges to run.
You should not generally log on using the local administrator account. The account that you use on a daily basis should not be a member of the local Administrators group. Sometimes you might still need an account that has administrative privileges — for example, when you install software or edit the registry. Because the default local administrator account is well known, however, and it is the target of many attacks, create a non-standard administrator account and use this only when it is required.
To create accounts for development
1. Remove your current user account from the Administrators group if it is a member.
2. Create a new custom administration account using a nonstandard name and strong password.
3. Use your non-administrator account to logon interactively on a daily basis. When you need to run a command with administrative privileges, use your custom administration account with the Runas.exe command line utility.
Running Privileged Commands
To run a privileged command, you can use one of the following techniques to temporarily change your security context:
• Use the Runas.exe utility from a command line. The following command shows you how to use the Runas.exe utility to launch a command console that runs under your custom administration account.
runas.exe /user:mymachine\mycustomadmin cmd.exe
By executing Cmd.exe, you start a new command window that runs under the security context of the user you specify with the /user switch. Any program you launch from this command window also runs under this context.
• Use Run As from Windows Explorer. You can right-click an executable file in Windows Explorer and click Run As. To display this item on Windows 2000 or Windows Server 2003, hold down the SHIFT key and then right-click an executable file. When you click Run As, you are prompted for the credentials of the account you want to use to run the executable file.
• Use Run As shortcuts. You can create quick launch and desktop shortcuts to easily run applications using a privileged user account. The following example shows a shortcut that you can use to run Windows Explorer (Explorer.exe) using the administrator account:
%windir%\System32\runas.exe /user:administrator explorer
Note If using a non-administrator account proves impractical for your environment, still test your application or component while running as a least privileged user to catch and correct problems before deploying. For example, your application might incorrectly require administrator privileges without your realizing it, which would cause the application to fail when it is deployed in a production environment.
Patch and Update
Ensure that your workstation has the latest service packs and patches. Check the operating system, IIS, SQL Server, MSDE, Microsoft Data Access Components (MDAC), and the .NET Framework. Microsoft offers several tools and methods to help you scan and update your system. These include the Windows Update site, the Microsoft Baseline Security Analyzer (MBSA) tool, and the Automatic Updates feature.
Using Windows Update
You can use Windows Update (available from the Start menu) to scan for updates and patches for Windows. Alternatively, you can directly scan for updates at http://windowsupdate.microsoft.com.
Note After you update your system using the Windows Update site, use MBSA to detect missing updates for SQL Server, MSDE, and MDAC.
Using MBSA
You can use MBSA to assess security and to verify patches. If you used automatic updates or Windows Update to update your operating system and components, MBSA verifies those updates and additionally checks the status of updates for SQL Server and Microsoft Exchange Server. MBSA lets you create a script to check multiple computers.
To detect and install patches and updates
1. Download MBSA from the MBSA home page at http://www.microsoft.com/technet/security/tools/mbsahome.asp.
If you do not have Internet access when you run MBSA, MBSA cannot retrieve the XML file that contains the latest security settings from Microsoft. You can use another computer to download the XML file, however. Then you can copy it into the MBSA program directory. The XML file is available at http://download.microsoft.com/download/xml/security/1.0/nt5/en-us/mssecure.cab.
2. Run MBSA by double-clicking the desktop icon or selecting it from the Programs menu.
3. Click Scan a computer. MBSA defaults to the local computer.
4. Clear all check boxes except for Check for security updates. This option detects which patches and updates are missing.
5. Click Start scan. Your server is now analyzed. When the scan completes, MBSA displays a security report, which it also writes to the %Userprofile%\SecurityScans directory.
6. Download and install the missing updates. Click Result details next to each failed check to view the list of missing security updates.
The resulting dialog box displays the Microsoft security bulletin reference number. Click the reference to find out more about the bulletin and to download the update.
For more information about using MBSA, see "How To: Use Microsoft Baseline Security Analyzer (MBSA)," in the How To section of this guide.
Note MBSA will not indicate required .NET Framework updates and patches. Browse the .NET Framework downloads page at http://msdn.microsoft.com/netframework/downloads/default.asp.
Using Automatic Updates
The Automatic Updates feature offers the easiest method to update your operating system with the latest critical security patches. The feature is built into Windows XP, Windows Server 2003 and is installed with Windows 2000 Service Pack 3.
To configure Automatic Updates with Windows 2000, click Automatic Updates in the Control Panel. For more information about Automatic Updates and Windows 2000, see Microsoft Knowledge Base article 327850, "How To: Configure and Use Automatic Updates in Windows 2000."
To configure Automatic Updates with Windows XP
1. Right-click the My Computer icon on the desktop or the System icon in Control Panel.
2. Click System Properties.
For more information about Automatic Updates and Windows XP, see Microsoft Knowledge Base article, 306525, "How To: Configure and Use Automatic Updates in Windows XP."
Note For more information about Automatic Updates for Windows Server 2003, see Microsoft Knowledge Base article 327838, "How to schedule automatic updates in Windows Server 2003, in Windows XP, and in Windows 2000."
Automatic Updates scans and installs updates for the following operating systems (including the .NET Framework and IIS where applicable):
• Microsoft Windows 2000 Professional
• Microsoft Windows 2000 Server
• Microsoft Windows XP Professional
• Microsoft Windows Server 2003
In addition to using Automatic Updates, use MBSA to detect missing updates for SQL Server, MSDE and MDAC.
Secure IIS
You often need to run IIS locally for Web development. If you run IIS, secure it. IISLockdown and URLScan significantly reduce your Web server's attack profile. IISLockdown points unused or forbidden script mappings to 404.dll and helps secure access to system directories and system tools. URLScan blocks known dangerous requests.
Although IISLockdown improves IIS security, if you choose the wrong installation options or do not modify the URLScan configuration file, URLScan.ini, you could encounter the following issues:
• You cannot create new ASP.NET Web applications. NTFS file system permissions are configured to strengthen default access to Web locations. This may prevent the logged on user from creating new ASP.NET Web applications.
• Cannot debug existing ASP.NET Web applications. URLScan blocks the DEBUG verb, which is used when you debug ASP.NET Web applications.
The following steps show you how to improve IIS security on your development workstation and avoid the issues listed above:
• Install and run IISLockdown
• Configure URLScan
• Restrict access to the local Web server
Install and Run IISLockdown
Note By default, IIS 6.0 has security-related configuration settings similar to those made by the IIS Lockdown Tool. Therefore you do not need to run the IIS Lockdown Tool on Web servers running IIS 6.0. However, if you are upgrading from a previous version of IIS (5.0 or lower) to IIS 6.0, it is recommended that you run the IIS Lockdown Tool to enhance the security of your Web server.
To install and run IISLockdown
1. Run the IISLockdown installation program (Iislockd.exe) from http://download.microsoft.com/download/iis50/Utility/2.1/NT45XP/EN-US/iislockd.exe.
Note If you run Iislockd.exe a second time, it removes all changes based on the log file \WINNT\System32\Inetsrv\oblt-log.log.
2. During setup, choose the Dynamic Web Site option, and choose the option to install URLScan. ASP.NET Web Forms use the HTTP POST verb. Choosing the static option and installing URLScan blocks the POST verb in URLScan.ini.
The Dynamic Web Site option does the following:
• Adds POST to the [AllowVerbs] section as shown below.
[AllowVerbs]
GET
HEAD
POST
• Disables the following Internet Services: Web service (HTTP), File Transfer Protocol (FTP), the Simple Mail Transport Protocol (SMTP) e-mail service, and the Network News Transport Protocol (NNTP) news service.
• Maps the following script maps to 404.dll: Index Server, Web Interface (.idq, .htw, .ida), server side includes (.shtml, .shtm, .stm), Internet Data Connector (.idc), HTR scripting (.htr), Internet printing (.printer)
• Removes the following virtual directories: IIS Samples, MSADC, IISHelp, Scripts, and IISAdmin.
• Restricts anonymous access to system utilities and the ability to write to Web content directories.
• Disables Web Distributed Authoring and Versioning (WebDAV).
• Installs the URLScan ISAPI filter.
Pitfalls
If you use IISLockdown, note the following pitfalls:
• IIS metabase updates can be lost. If you undo IISLockdown changes by running Iislockd.exe a second time, you lose any changes made to the IIS metabase since the last time IISLockdown was run. For example, if you configure a virtual directory as an application root after running IIS lockdown, that change is lost when you run IISLockdown again.
• Resources are blocked by 404.dll. If you receive a 404 error for a previously available resource, it might be because the resource type is blocked by 404.dll. To confirm whether or not this is the case, check the script mapping for the requested resource type in IIS.
Configure URLScan
The URLScan ISAPI filter installs when you run IISLockdown. If you do not explicitly allow the DEBUG verb, URLScan prevents debugging. Also, URLScan blocks requests that contain unsafe characters such as the period (.) used for directory traversal.
Note IIS 6.0 on Windows Server 2003 has functionality equivalent to URLScan built in. Your decision whether to implement UrlScan should be based on your organization's specific requirements. For more information and guidance, see "Installing UrlScan 2.5" at http://www.microsoft.com/technet/security/tools/urlscan.mspx#EEAA.
To configure URLScan, edit URLScan.ini in %Windir%\System32\inetsrv\urlscan\. To allow debugging with URLScan, add DEBUG to the [AllowVerbs] section in URLScan.ini as shown below.
[AllowVerbs]
GET
HEAD
POST
DEBUG
Pitfalls
If you install URLScan, note the following pitfalls:
• When you debug an application by using Visual Studio.NET, you may see the following error:
Microsoft Development Environment:
Error while trying to run project: Unable to start debugging on the Web server. Could not start ASP.NET or ATL Server debugging.
Verify that ASP.NET or ATL Server is correctly installed on the server. Would you like to disable future attempts to debug ASP.NET pages for this project?
You should see a log entry similar to the one shown below in URLScan.log in the \WINNT\system32\inetsrv\urlscan folder.
[02-08-2008- 22:25:26] Client at 127.0.0.1: Sent verb 'DEBUG', which is not specifically allowed. Request will be rejected.
• Requests that you expect to work might get blocked.
• You may not be able to create new Web projects in Visual Studio .NET because you use characters in the project name that URLScan rejects. For example, the comma (,) and the pound sign (#) will be blocked.
If you experience errors during debugging, see Microsoft Knowledge Base article 306172, "INFO: Common Errors When You Debug ASP.NET Applications in Visual Studio .NET," at http://support.microsoft.com/default.aspx?scid=kb;EN-US;306172.
Secure SQL Server and MSDE
To update SQL Server and MSDE, you must:
• Apply patches for each instance of SQL Server and MSDE
• Analyze SQL Server and MSDE security configuration
Apply Patches for Each Instance of SQL Server and MSDE
MSDE shares common technology with SQL Server, and it enables developers, partners, and IT professionals to build database applications without requiring the full SQL Server product. MSDE can be packaged with applications that require database support. To apply patches to MSDE, you must know which application installed it on your system. This is important because you must obtain the patch for MSDE from the product vendor.
For more information on applications that include MSDE, refer to the following resources:
• "Microsoft Products That Include MSDE," at http://www.microsoft.com/technet/security/bulletin/msdeapps.mspx
• "SQL Server/MSDE-Based Applications," at http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=31
If your third-party vendor does not supply a patch for MSDE, and if it becomes critical to have the latest patches, you can only do the following:
• Uninstall the instance of SQL Server using Add/Remove Programs. If you do not see an uninstall option for your instance, you might need to uninstall your application.
• Stop the instance of SQL Server using the Services MMC snap-in in Computer Management. You can also stop the instance from the command line by running the following command:
net stop mssqlserver (default instance), mssql$instancename (for instances)
• Use IPSec to limit which hosts can connect to the abandoned (unpatched) instances of SQL Server. Restrict access to localhost clients.
Analyze SQL Server and MSDE Security Configuration
Use MBSA to analyze your Microsoft SQL Server or MSDE configuration on your workstation.
To analyze SQL Server and MSDE security configuration
1. Run MBSA by double-clicking the desktop icon or selecting it from the Programs menu.
2. Click Scan a computer. MBSA defaults to the local computer.
3. Clear all check boxes except for Check for SQL vulnerabilities.
This option scans for security vulnerabilities in the configurations of SQL Server 7.0, SQL Server 2000, and MSDE. For example, it checks the authentication mode, the sa account password, and the SQL Server service account, among other checks.
A number of the checks require that your instance of SQL Server is running. If it is not running, start it.
4. Click Start scan. Your configuration is now analyzed. When the scan completes, MBSA displays a security report, which it also writes to the %Userprofile%\SecurityScans directory.
5. Review the failed checks, and fix vulnerable configuration settings.
Click Result details next to each failed check for more information about why the check failed. Click How to correct this, for information about how to fix the vulnerability.
For more information about using MBSA, see "How To: Use Microsoft Baseline Security Analyzer (MBSA)," in the How To section of this guide.
Evaluate Your Configuration Categories
To evaluate the security of your workstation configuration, review the configuration categories shown in Table. Start by using the categories to evaluate the security configuration of the base operating system. Then apply the same configuration categories to review your IIS, SQL Server, and .NET Framework installation.
Configuration Categories
Configuration Category Methodology
Patches and updates Setup Automatic Updates. Use MBSA or Windows Updates to verify that the latest updates are installed
Services Disable unused services.
Protocols Check that SMB and NetBIOS over TCP are removed if your workstation is not a member of a domain.
Accounts Check that all local accounts use strong passwords.
Files and directories Be sure your workstation uses only NTFS partitions.
Shares Enumerate shares, remove unnecessary ones, and secure the remaining ones with restricted permissions.
Ports Ensure that unused ports are closed by disabling the service that has the port open. To verify which ports are listening use the netstat –n –a command.
Registry Disable null sessions.
Auditing and logging Audit failed Windows attempts to log on and log failed actions across the file system.
Stay Secure
Monitor the security state of your workstation, and update it regularly to help prevent newly discovered vulnerabilities from being exploited.

Saturday, January 26, 2008


My family, scattered to the four winds, has a dangerous habit of blindly clicking through software installs and downloading all kinds of junk from the Internet. That's why I hear "The PC is acting funny" a lot. Not long ago an effective fix had to wait until my next visit, but now I can repair the damage anytime from my home or office using the free UltraVNC remote control software).

You can install and use UltraVNC in several different ways; in my experience, it's easiest for the person I'm helping if I run the remote viewer on my machine, and then send a simple applet to them via an e-mail attachment that they click to automate the link to my system.

To set up UltraVNC on your PC, install the application and select Run UltraVNC Viewer (Listen Mode) on the program's Start menu. If you have a router, you may have to open a port (the UltraVNC's default is 5500) to redirect traffic to your local computer. The method for doing this varies from router to router, so check your device?s documentation or the vendor Web site.

Locate your IP address

Next, customize the UltraVNC SC (for "single-click") server, which initiates the connection. Go to download custom.zip (look for the link about a third of the way down). Open the zipped file on your PC, and double-click helpdesk.txt to open that file. Replace both IP addresses (192.168.1.102) under the [HOST] headings with the address assigned to you by your ISP. Leave everything but those four numbers unchanged. If you're routerless, visit www.whatismyipaddress.com and note the number shown there.

Most home IP addresses change from log-on to log-on (this arrangement is called dynamic IP addressing). If you need to create a static IP address, visit the free DynDNS service. You must run the service's utility to update its redirect table every time your local IP address changes? Without DynDNS, you'd have to re-edit and recompile the helpdesk.txt file every time you reloaded your Net connection.

Send them a panic button

Save the helpdesk.txt file back to the custom.zip archive. Next, browse to UltraVnc SC online creator, enter foo in the Userid field and foobar as the password, and click Browse to navigate to and select the custom.zip file. Click Upload, and it about 5 seconds you'll be told to download the custom.exe file that the remote user must click to connect to your machine. E-mail the custom.exe file (or whatever you rename it) to your family members, or post it on your Web site for them to download. When they follow the simple installation instructions that accompany it, you will see a dialog box on your screen informing you of an incoming connection. Accept it, and their Windows desktop appears in a window on your screen, ready for you to control. UltraVNC is free.

Friday, September 28, 2007

Internet Information Service (IIS) 7.0

IIS version 7.0 is a major enhancement to the existing IIS Web server and plays a central role in integrating Web platform technologies.

IIS 7.0 is built to be compatible with existing releases. All existing ASP, ASP.NET 1.1, and ASP.NET 2.0 applications are expected to run on IIS 7.0 without any code changes (using the compatible ISAPI support).

All existing ISAPI extensions and most ISAPI filters will also continue to work, unchanged. However, ISAPI filters that rely on READ RAW DATA notification are not supported in IIS 7.0

Who will be interested in this feature?

Any business or organization that hosts or develops Web sites or WCF services can benefit from the improvements made in IIS 7.0.

You should review this topic, and the additional supporting documentation on IIS 7.0, if you are in any of the following groups:

· IT planners and analysts who are technically evaluating the product

· Enterprise IT planners and designers for organizations

· IT professionals who deploy or administer IIS

· Developers who create Web sites or WCF services

· Internet Service Providers (ISPs) or similar organizations that provide Web hosting

Please find the full document which you can download from the file sharing section of live space.

http://cid-80e0d4743a9bf96c.skydrive.live.com/self.aspx/Public/Web%20Server(IIS7).doc

Monday, September 10, 2007

Implementing
Application Security Using the Microsoft .NET Framework


In this article we are going to discuss the application security using Microsoft® .NET Framework. Specifically, we will discuss:

 .NET Framework security features.
 Code access security.
 Role-based security.
 Cryptography.
 Securing Microsoft ASP.NET Web applications.
 Securing ASP.NET Web services.


I assume that reader have Development experience with Microsoft Visual Basic®, Microsoft Visual C++®, or C#
Experience building Microsoft Windows® or Web applications using the .NET Framework.

The .NET common language runtime controls the execution of .NET code. The .NET Framework security system is part of the common language runtime.
The .NET Framework includes many features that you will cover soon in this article, such as type checking for safe type-conversions, secure exception management, and code access security control.
.NET Framework security is designed to complement the security provided by Microsoft Windows®. It does not override Windows-based security. For example, if a Windows access control list (ACL) restricts access to a file, the .NET Framework does not override this security.

.NET Managed Execution Security
The .NET Framework security features
Assist you in developing secure applications
Include many components, including:
Type Checker
Exception Manager
Security Engine
Complement Windows Security

A Type-Safe System
Type-safe code:
Prevents buffer overruns
Restricts access to authorized memory locations
Allows multiple assemblies to run in the same process

App Domains provide:
Increased performance
Increased code security

Type-safety verification is the cornerstone of .NET Framework security because it prevents access to unauthorized memory locations. This allows you to consistently enforce security policy. For example, code cannot overrun a buffer and cause execution to jump to an arbitrary memory location.
Type-safety verification allows the common language runtime to run more than one type-safe assembly in the same process. These sub-processes are called application domains. Application domains are especially useful in server scenarios in which the overhead of using many processes may slow system performance.
In the past, the use of dynamic-link library (DLL)-based components was preferred for efficiency reasons, because EXE-based components were seen to be more secure and robust (due to the Microsoft Win32® virtual address space architecture). However, .NET supports the concept of an App Domain. An App Domain can be thought of as a process within a process, which provides good performance (like a DLL-based component), excellent security, and robustness.


• Managed code typically does not deal with raw pointers (such as a char *). Instead, the .NET runtime uses classes such as System.String and System.Text.StringBuilder, which are managed by .NET type-verification checks.
• A String is an immutable object, which vastly alleviates the buffer overrun issue. Consider the following code:

void CopyString (string src)
{
stringDest = src;
}

When the code executes, a new resultant string object will be created, and the reference stringDest will be altered to refer to that string. Therefore, a buffer overrun is not possible.
Another string class found in the .NET Framework is StringBuilder. StringBuilder is also a robust class and will throw an exception if an attempt is made to overwrite its internal buffer.

Trapping arithmetic errors in unmanaged code (for example, Visual C++) is very difficult. However, with managed code, spotting arithmetic runtime errors is easier. For example, the Visual C# compiler enables automatic checking for arithmetic overflows and underflows.
• By default, the arithmetic error trapping feature is turned off (for optimization reasons). However, you can easily turn on this feature either from the project properties or by using the checked keyword in your code.
• If you have turned arithmetic checking on at the project level, you can override the settings by using the unchecked keyword in your code. This is useful if you are certain that arithmetic errors cannot occur in specific blocks of code and you want to optimize those blocks when your code is compiled.
In few moments, you will see:
• How .NET data-type safety works.
• How to use the checked keyword.

Strong-Named Assemblies
Strong names are unique identifiers for your assemblies. You can generate strong names and then use them to digitally sign your assemblies. Strong-naming solves problems (such as version control and backward compatibility issues) that are caused when components are shared by multiple applications. In effect, strong names associate a distinct build of a component assembly with the client application. A distinct build is indicated by a combination of a version number and a special value that is called the publicKeyToken.
You can generate a public/private key pair for signing your assembly by using the Strong Name tool (Sn.exe).

Isolated Storage
Provides a virtual file system
Allows quotas
Implements file system isolation based on:
Application identity
User identity
IsolatedStorageFile isoStore =
IsolatedStorageFile.GetUserStoreForAssembly();

For some applications, such as downloaded Web applications and code that may come from sources that are not trusted, the basic file system does not provide the necessary isolation and safety. Isolated storage is a data storage mechanism that provides isolation and safety by defining standardized ways of associating code with saved data

With isolated storage, developers no longer have to invent unique paths to specify safe locations in the file system. Developers can now access safe locations by using either the application's identity or the user's identity. The code sample on the slide show an example of how to access the isolated storage based on a user's identity

These are the main .net Security features and we will cover other portions soon. Any comments and questions are acceptable. (maneeshpnair@msn.com). Accept my advance apology for any delayed response as I am in rest.
Forthcoming sections include code access security, Securing ASP.NET Web applications etc.. (Visit: http://maneeshpnair.spaces.live.com/)

Monday, August 6, 2007

Why application security matters

Because computers are an important component of any business, they need to:

Be reliable.

Be able to withstand security attacks.

Provide a feeling of confidence to both businesses and individuals that their data is secure

Source of Attacks.

Workforce mobility is increasing, and consequently, the way in which employees connect to your company’s network is evolving. Employees connect in a number of different ways, including traditional wired connections, new and evolving wireless network standards, and dial-up and broadband virtual private network (VPN) connections. The variety of ways your mobile users connect to your company’s network introduces a number of security concerns.

Applications are becoming increasingly dependant on connections to the Internet, for updated data, Web services, and so on. The Internet is a potential route to your systems for attackers and viruses. Many businesses require a persistent connection to the Internet so that they can provide Web sites, File Transfer Protocol (FTP) site, and Web services. As already stated, the Internet is a potential route to your systems for attackers and viruses

There are many types of attacks which need more pages to explain. Point of this article is to generate an idea on Secure Application Development Practices. Even if you have the most secure network infrastructure possible, with completely hardened servers, a simple vulnerability in your application (for example, failing to validate input) renders all of that useless

The Developer Role in Application Security

Solution architects, developers, and systems administration personnel must all work together and take collective responsibility for security.

Developers must adopt good practices that ensure the production of secure software. They must be knowledgeable about security vulnerabilities and how to avoid them, and must have both a broad and deep knowledge about security technologies and how to use them in order to create secure solutions

Developers must:

Work with solution architects and systems administrators to ensure application security

Contribute to security by:

Adopting good application security development practices

Knowing where security vulnerabilities occur and how to avoid them

Using secure programming techniques

The SD3 Security Framework

Secure by Design

Secure by Default

Secure in Deployment

  • Secure architecture and code
  • Threat analysis
  • Vulnerability reduction

Attack surface area reduced

Unused features turned off by default

Minimum privileges used

  • Protection: Detection, defense, recovery, management
  • Process: How to guides, architecture guides
  • People: Training

Secure by Design means that you have taken the appropriate steps to ensure that the overall design of the product is secure from the outset. Include threat modeling at the design phase and throughout the project to identify potential vulnerabilities. Use secure design, coding, and testing guidelines.

Secure by Default means that the product is released so that it is secure out of the box. If features are optional, and you can turn them off by default. If a feature is not activated, then an attacker cannot use it to compromise your product. Ensure that only the least amount of privilege is required by user accounts to run your application. Then a compromise can have less serious consequences than if an attacker is able to run malicious code under an account with administrator privileges. Ensure that effective access controls are in place for resources.

Secure in Deployment means that the system is maintainable after installation. If a product is difficult to administer, it makes it more difficult to maintain protection against security threats as new ones evolve. Ensure that users are educated to use the system in a secure manner. If security vulnerability is discovered and a patch is necessary, ensure that the fix is fully tested internally and then issued in a timely manner.

Thank you for your time and interest. It’s just a step to explain today’s trend in application development, and most of you aware with this. Any comments and questions are acceptable. (maneeshpnair@msn.com). Forthcoming articles include Secure Development Process, Threat Modeling, Risk Mitigation and Security Best Practices (Visit: http://maneeshpnair.spaces.live.com/ , http://maneeshpnair.blogspot.com/ , http://360.yahoo.com/maneeshpnair )

Friday, July 20, 2007

Social Engineering

Social engineering is a collection of techniques used to manipulate people into performing actions or divulging confidential information

Social engineering takes advantage of the lack of concern for security in the daily lives of most people. An attacker can spend time at work or leisure getting to know users and gaining their confidence. While an attacker asks questions and gains information that on a per-answer basis does not appear harmful, the information taken as a whole provides the attacker with the means to start or carry out an attack.

take good care...A known stranger may filch your password or PII (personally identifiable information ).

Friday, July 13, 2007

Windows 2003 Server

How demote a childdomain without parent domain or forest?

Use dcpromo /forceremoval