Marketing a Custom Software

Custom software is specially developed for some specific Custom Software Development company or other user with specific needs. As such, it can be contrasted with the use of software packages developed for the mass market, such as commercial off-the-shelf (COTS) software, or existing free software.

Custom software development is often considered expensive compared to off-the-shelf solutions or products. This can be true if one is speaking of typical challenges and typical solutions. However, it is not always true; custom software development by a reputable supplier is often a matter of building a house upon a solid foundation and, if managed properly, it is possible to do this quickly and to a high standard. In many cases, COTS software requires customization to correctly support the buyer's operations. The cost and delay of COTS customization frequently adds up to the expense of developing custom software.

Business processes are an important intellectual property for any software development organization. Fine-tuning and enforcing your processes through smart, fully-automated applications can help set your company apart from your competitors. Most custom software companies in India don't market their product correctly. Marketing should focus not on products but on customers. If marketing were supposed to focus the product, it would be called “producting.”But it's not is it? It's called “marketing,” which means that marketing is supposed to focus on the marketplace—and the marketplace is made up of people: customers and prospects. This focus on marketplace instead of product must form the basis of your strategic and tactical marketing—when you lose this focus your marketing loses its meaning. Start off by segmenting your market.

There are some option for creating marketing strategies. Try company size and industry sector as variables. i.e. you are looking for medium sized companies in the financial services sector. The company size and industry sector would be dependent on the previous experience of your team. Speaking of that, have you got case studies on your previous engagements? Client testimonials are also good. Your revenue comes from services. Your revenue does not come from custom software development in isolation. Position yourself to as a services firm that provides solution. Your solutions should solve business problems. What problems do your solutions solve? What problems do your clients/prospects have? Do you provide customization of 'boxed product'? Do you improve system performance or functionality? Do your solutions provide benefit to the technical side or the end-user side? What does your service methodology provide that other service providers don't? Who benefits the most from your solutions and how? The answer to these questions will build your value proposition and create a compelling story that clients will want to hear!

Identify your niche by analysing your past project successes. And ask some questions to yourself. like:

• What technologies were used?
• What business department did you serve?
• What business process or function did you improve?
• Did you save your client money?
• Did you improve a process?
• What industry did you serve?

Break these criteria down into a basis and you will start to see where your company has been successful - then you can begin to replicate that success.

According to those criteria plan strategy for marketing your custom software.

Some common marketing methods are as follows :

• Continuous Search Engine Optimization
• Affiliates marketing
• Write newsletters and press releases
• Get involved in online forums and blogs

Thus, the custom software development companies in India should use these strategies and points while marketing the custom software.

Risk Analysis

Introduction

The objective of a security program is to mitigate risks. Mitigating risks does not mean eliminating them; it means reducing them to an acceptable level. To make sure your security controls are effectively controlling the risks in your environment, you need to anticipate what kinds of incidents may occur. You also need to identify what you are trying to protect, and from whom. That’s where risk analysis, threat definition, and vulnerability analysis come in. What is being protected? What are the threats? And where are the weaknesses that may be exploited?

Threat Definition

Evaluating threats is an important part of risk analysis. By identifying threats, you can give your security strategy focus and reduce the chance of overlooking important areas of risk that might otherwise remain unprotected. Threats can take many forms, and in order to be successful, a security strategy must be comprehensive enough to manage the most significant threats.

How do you know you’re defending against the right threats?

For example, if an software development organization were to simply purchase and install a firewall (and do nothing else) without identifying and ranking the various threats to their most important assets, would they be secure? Probably not. These statistics are from Verizon’s 2010 Data Breach Investigations Report (DBIR), the result of a collaboration between Verizon and the U.S. Secret Service. This is a breakdown of “threat agents,” which are defined in the report as “entities that cause or contribute to an incident.” 

This particular study illustrates the point that insider threats should be an important consideration in any security program. Many people that haven’t seen real-world security breaches don’t know this, so they focus exclusively on external threats.

There are numerous other studies that show different results, including later DBIR reports (because different environments experience different threats, and the threat landscape always changes) but they all point to the insider threat as a serious concern. Security professionals know that many real-world threats come from inside the organization, which is why just building a wall around your trusted interior is not good enough. Regardless of the breakdown for your particular organization, you need to make sure your security controls focus on the right threats. To avoid overlooking important threat sources, you need to consider all types of threats.

This consideration should take into account the following aspects of threats:

• Threat vectors
• Threat sources and targets
• Types of attacks
• Malicious mobile code
• Advanced Persistent Threats (APTs)
• Manual attacks

Threat Vectors

A threat vector is a term used to describe where a threat originates and the path it takes to reach a target. An example of a threat vector is an e-mail message sent from outside the software development organization to an inside employee, containing an irresistible subject line along with an executable attachment that happens to be a Trojan program, which will compromise the recipient’s computer if opened.

A good way to identify potential threat vectors is to create a table containing a list of threats you are concerned about. It is important to understand threat vectors and consider them when designing security controls, to ensure that possible routes of attack for the various threats receive appropriate scrutiny. Understanding threat vectors is also important for explaining to others, such as management, how the protective mechanisms work and why they are important.

Risk Analysis

A risk analysis needs to be a part of every security effort. It should analyze and categorize the assets that need to be protected and the risks that need to be avoided, and it should facilitate the identification and prioritization of protective elements. It can also provide a means to measure the effectiveness of the overall security architecture, by tracking those risks and their associated mitigation over time to observe trends. How formal and extensive should your risk analysis be? That really depends on the needs of your organization and the audience for the information. In a larger, well structured environment, a more detailed risk analysis may be needed. 

A quantitative approach to risk analysis will take into account actual values—the estimated probability or likelihood of a problem occurring along with the actual cost of loss or compromise of the assets in question. One commonly used approach to assigning cost to risks is annualized loss expectancy (ALE). This is the cost of an undesired event—a single loss expectancy (SLE)—multiplied by the number of times you expect that event to occur in one year—the annualized rate of occurrence (ARO).

Annualized Loss (ALE) = Single Loss (SLE) * Annualized Rate (ARO).

But there are problems with the ALE approach. How can you assign ARO to every potential loss? For example, how many times a year will your car be involved in a fender bender? In reality, many years may go by in between accidents, but occasionally you may have two or three accidents in a single year. Thus, your ARO can be highly variable. Even defining SLE can be difficult. How much will a fender-bender cost? It could be anywhere from nothing to several thousand dollars. An analytical mind might be bothered by the variability and ambiguousness of the numbers. In fact, there is a lot of guesswork involved.

Because the results of an ALE analysis are hard to defend, prove, support, and demonstrate, this approach is tending to fall out of favor. However, the basic principle of identifying threats, vulnerabilities, and risks remains valid. 

A qualitative approach to risk analysis, which may suffice in smaller environments or those with limited resources, can be just as effective. In an software development company, You can identify your assets (for example, a web server, a database containing confidential information, workstation computers, and a network). You can identify the threats to those assets (malware, hack attacks, bugs and glitches, power outages, and so forth). And you can assign a severity level to help you prioritize your remediation. If the severity is high enough, you will probably want antivirus capability on the endpoints as well as on the network, a high-quality stateful firewall, a timely patching program that includes testing, and uninterrupted power supplies (UPSs).

Thus, a proper risk analysis should be carried out to mitigate the risk occurring in an organization. 

Computer & Network Policies in Information Security : Part-2

Network Policies

This group of policies applies to the network infrastructure to which computer systems are attached and over which data travels in a software development organization. Policies relating to network traffic between computers can be the most variable of all, because an organization’s network is the most unique component of its computing infrastructure, and because organizations use their networks in different ways. These example policies may or may not apply to your particular network, but they may provide inspiration for policy topics you can consider. 

• Extranet Connection Access Control: All extranet connections (connections to and from other organizations’ networks outside of the organization, either originating from the external organization’s remote network into the internal network, or originating from the internal network going out to the external organization’s remote network) must limit external access to only those services authorized for the remote organization. This access control must be enforced by IP address and TCP/UDP port filtering on the network equipment used to establish the connection. 

• System Communication Ports: Systems communicating with other systems on the local network must be restricted only to authorized communication ports. Communication ports for services not in use by operational software must be blocked by firewalls or router filters. 

• Inbound Internet Communication Ports: Systems communicating from the Internet to internal systems must be restricted to use only authorized communication ports. Firewall filters must block communication ports for services not in use by operational system software. The default must be to block all ports, and to make exceptions to allow specific ports required by system software. 

• Outbound Internet Communication Ports: Systems communicating with the Internet must be restricted to use only authorized communication ports. Firewall filters must block communication ports for services not in use by operational system software. The default must be to block all ports, and to make exceptions to allow specific ports required by system software. 

• Unauthorized Internet Access Blocking: All users must be automatically blocked from accessing Internet sites identified as inappropriate for the organization’s use. This access restriction must be enforced by automated software that is updated frequently.

• Extra net Connection Network Segmentation: All extranet connections must be limited to separate network segments not directly connected to the corporate network.

• Virtual Private Network: All remote access to the corporate network is to be provided by virtual private network (VPN). Dial-up access into the corporate network is not allowed. 

• Virtual Private Network Authentication: All virtual private network connections into the corporate network in an IT software development company require token-based or biometric authentication.  Employee and contractor home systems may connect to the corporate network via a virtual private network only if they have been installed with a corporate-approved, standard operating system configuration with appropriate security patches as well as corporate-approved personal firewall software or a network firewall device.

Author Signature: Venu Majmudar