Startup Comp Structure

You’ve decided to start a company. Your business plan is based on sound strategy and thorough market research. Your background and training have prepared you for the challenge. Now you must assemble the quality management team that venture investors demand. So you begin the search for a topflight engineer to head product development and a seasoned manager to handle marketing, sales, and distribution.

Attracting these executives is easier said than done. You’ve networked your way to just the marketing candidate you need: a vice president with the right industry experience and an aggressive business outlook. But she makes $100,000 a year in a secure job at a large company. You can’t possibly commit that much cash, even if you do raise outside capital. How do you structure a compensation package that will lure her away? How much cash is reasonable? How much and what type of stock should the package include? Is there any way to match the array of benefits—retirement plans, child-care assistance, savings programs—her current employer provides? In short, what kind of compensation and benefits program will attract, motivate, and retain this marketing vice president and other key executives while not jeopardizing the fragile finances of your startup business?

Selecting appropriate compensation and benefits policies is a critical challenge for companies of all sizes. But never are the challenges more difficult—or the stakes higher—than when a company first takes shape. Startups must strike a delicate balance. Unrealistically low levels of cash compensation weaken their ability to attract quality managers. Unrealistically high levels of cash compensation can turn off potential investors and, in extreme cases, threaten the solvency of the business. How to proceed?

First, be realistic about the limitations. There is simply no way that a company just developing a prototype or shipping product for less than a year or generating its first black ink after several money-losing years of building the business can match the current salaries and benefits offered by established competitors. At the same time, there are real advantages to being small. Without an entrenched personnel bureaucracy and long-standing compensation policies, it is easier to tailor salaries and benefits to individual needs. Creativity and flexibility are at a premium.

Second, be thorough and systematic about analyzing the options. Compensation and benefits plans can be expensive to design, install, administer, and terminate. A program that is inappropriate or badly conceived can be a very costly mistake. Startups should evaluate compensation and benefits alternatives from four distinct perspectives.

How do they affect cash flow? Survival is the first order of business for a new company. Even if you have raised an initial round of equity financing, there is seldom enough working capital to go around. Research and development, facilities and equipment, and marketing costs all make priority claims on resources. Cash compensation must be a lower priority. Despite this awkward tension (the desperate need to attract first-rate talent without having the cash to pay them market rates), marshaling resources for pressing business needs must remain paramount.

What are the tax implications? Compensation and benefits choices have major tax consequences for a startup company and its executives; startups can use the tax code to maximum advantage in compensation decisions. Certain approaches, like setting aside assets to secure deferred compensation liabilities, require that executives declare the income immediately and the company deduct it as a current expense. Other approaches, like leaving deferred compensation liabilities unsecured, allow executives to declare the income later while the company takes a future deduction. Many executives value the option of deferring taxable income more than the security of immediate cash. And since most startups have few, if any, profits to shield from taxes, deferring deductions may appeal to them as well.

What is the accounting impact? Most companies on their way to an initial public offering or a sellout to a larger company must register particular earning patterns. Different compensation programs affect the income statement in very different ways. One service company in the startup stage adopted an insurance-backed salary plan for its key executives. The plan bolstered the company’s short-term cash flow by deferring salary payments (it also deferred taxable income for those executives). But it would have meant heavy charges to book earnings over the deferral period—charges that might have interfered with the company’s plans to go public. So management backed out of the program at the eleventh hour.

What is the competition doing? No startup is an island, especially when vying for talented executives. Companies must factor regional and industry trends into their compensation and benefits calculations. One newly established law firm decided not to offer new associates a 401(k) plan. (This program allows employees to contribute pretax dollars into a savings fund that also grows tax-free. Many employers match a portion of their employees’ contributions.) The firm quickly discovered that it could not attract top candidates without the plan; it had become a staple of the profession in that geographic market. So it established a 401(k) and assumed the administrative costs, but it saved money by not including a matching provision right away.

Events at a Boston software company illustrate the potential for flexibility in startup compensation. The company’s three founders had worked together at a previous employer. They had sufficient personal resources to contribute assets and cash to the new company in exchange for founders’ stock. They decided to forgo cash compensation altogether for the first year.

Critical to the company’s success were five software engineers who would write code for the first product. It did not make sense for the company to raise venture capital to pay the engineers their market-value salaries. Yet their talents were essential if the company were to deliver the software on time.

The obvious solution: supplement cash compensation with stock. But two problems arose. The five prospects had unreasonably high expectations about how much stock they should receive. Each demanded 5% to 10% of the company, which, if granted, would have meant transferring excessive ownership to them. Moreover, while they were equal in experience and ability and therefore worth equal salaries, each had different cash requirements to meet their obligations and maintain a reasonable life-style. One of the engineers was single and had few debts; he was happy to go cash-poor and bank on the company’s growth. One of his colleagues, however, had a wife and young child at home and needed the security of a sizable paycheck.

The founders devised a solution to meet the needs of the company and its prospective employees. They consulted other software startups and documented that second-tier employees typically received 1% to 3% ownership stakes. After some negotiation, they settled on a maximum of 2% for each of the five engineers. Then they agreed on a formula by which these employees could trade cash for stock during their first three years. For every $1,000 in cash an engineer received over a base figure, he or she forfeited a fixed number of shares. The result: all five engineers signed on, the company stayed within its cash constraints, and the founders gave up a more appropriate 7% of the company’s equity.

Cash vs. Stock

Equity is the great compensation equalizer in startup companies—the bridge between an executive’s market value and the company’s cash constraints. And there are endless variations on the equity theme: restricted shares, incentive stock options, nonqualified options, stock appreciation rights (SARs), phantom stock, and the list goes on. This dizzying array of choices notwithstanding, startup companies face three basic questions. Does it make sense to grant key executives an equity interest? If so, should the company use restricted stock, options, or some combination of both? If not, does it make sense to reward executives based on the company’s appreciating share value or to devise formulas based on different criteria?

Let’s consider these questions one at a time. Some company founders are unwilling to part with much ownership at inception. And with good reason. Venture capitalists or other outside investors will demand a healthy share of equity in return for a capital infusion. Founders rightly worry about diluting their control before obtaining venture funds.

Alternatives in this situation include SARs and phantom shares—programs that allow key employees to benefit from the company’s increasing value without transferring voting power to them. No shares actually trade hands; the company compensates its executives to reflect the appreciation of its stock. Many executives prefer these programs to outright equity ownership because they don’t have to invest their own money. They receive the financial benefits of owning stock without the risk of buying shares. In return, of course, they forfeit the rights and privileges of ownership. These programs can get complicated, however, and they require thorough accounting reviews. Reporting rules for artificial stock plans are very restrictive and sometimes create substantial charges against earnings.

Some founders take the other extreme. In the interest of saving cash, they award bits of equity at every turn. This can create real problems. When it comes to issuing stock, startups should always be careful not to sell the store before they fill the shelves. That is, they should award shares to key executives and second-tier employees in a way that protects the long-term company interest. And these awards should take place only after the company has fully distributed stock to the founders.

The choice of whether to issue actual or phantom shares should also be consistent with the company’s strategy. If the goal is to realize the “big payoff” within three to five years through an initial public offering or outright sale of the company, then stock may be the best route. You can motivate employees to work hard and build the company’s value since they can readily envision big personal rewards down the road.

The founder of a temporary employment agency used this approach to attract and motivate key executives. He planned from the start to sell the business once it reached critical mass, and let his key executives know his game plan. He also allowed them to buy shares at a discount. When he sold the business a few years later for $10 million, certain executives, each of whom had been allowed to buy up to 4% of the company, received as much as $400,000. The lure of cashing out quickly was a great motivator for this company’s top executives.

For companies that plan to grow more slowly over the first three to five years, resist acquisition offers, and maintain private ownership, the stock alternative may not be optimal. Granting shares in a company that may never be sold or publicly traded is a bit like giving away play money. Worthless paper can actually be a demotivator for employees.

In such cases, it may make sense to create an artificial market for stock. Companies can choose among various book-value plans, under which they offer to buy back shares issued to employees according to a pricing formula. Such plans establish a measurement mechanism based on company performance—like book value, earnings, return on assets or equity—that determines the company’s per-share value. As with phantom shares and SARs, book-value plans require a thorough accounting review.

If a company does decide to issue shares, the next question is how to do it. Restricted stock is one alternative. Restricted shares most often require that an executive remain with the company for a specified time period or forfeit the equity, thus creating “golden handcuffs” to promote long-term service. The executive otherwise enjoys all the rights of other shareholders, except for the right to sell any stock still subject to restriction.

Stock options are another choice, and they generally come in two forms: incentive stock options (ISOs) and nonqualified stock options (NSOs). As with restricted shares, stock options can create golden handcuffs. Most options, whether ISOs or NSOs, involve a vesting schedule. Executives may receive options on 1,000 shares of stock, but only 25% of the options vest (i.e., executives can exercise them) in any one year. If an executive leaves the company, he or she loses the unexercised options. Startups often prefer ISOs since they give executives a timing advantage with respect to taxes. Executives pay no taxes on any capital gains until they sell or exchange the stock, and then only if they realize a profit over the exercise price. ISOs, however, give the company no tax deductions—which is not a major drawback for startups that don’t expect to earn big profits for several years. Of course, if companies generate taxable income before their executives exercise their options, lack of a deduction is a definite negative.

ISOs have other drawbacks. Tax laws impose stiff technical requirements on how much stock can be subject to options, the maximum exercise period, who can receive options, and how long stock must be held before it can be sold. Moreover, the exercise price of an ISO cannot be lower than the fair market value of the stock on the date the option is granted. (Shares need not be publicly traded for them to have a fair market value. Private companies estimate the market value of their stock.)

For these and other reasons, companies usually issue NSOs as well as ISOs. NSOs can be issued at a discount to current market value. They can be issued to directors and consultants (who cannot receive ISOs) as well as to company employees. And they have different tax consequences for the issuing company, which can deduct the spread between the exercise price and the market price of the shares when the options are exercised.

NSOs can also play a role in deferred compensation programs. More and more startups are following the lead of larger companies by allowing executives to defer cash compensation with stock options. They grant NSOs at a below-market exercise price that reflects the amount of salary deferred. Unlike standard deferral plans, where cash is paid out on some unalterable future date (thus triggering automatic tax liabilities), the option approach gives executives control over when and how they will be taxed on their deferred salary. The company, meanwhile, can deduct the spread when its executives exercise their options.

One small but growing high-tech company used a combination of stock techniques to achieve several compensation goals simultaneously. It issued NSOs with an exercise price equal to fair market value (most NSOs are issued at a discount). All the options were exercisable immediately (most options have a vesting schedule). Finally, the company placed restrictions on the resale of stock purchased with options.

This program allowed for maximum flexibility. Executives with excess cash could exercise all their options right away; executives with less cash, or who wanted to wait for signs of the company’s progress, could wait months or years to exercise. The plan provided the company with tax deductions on any options exercised in the future (assuming the fair market value at exercise exceeded the stock’s fair market value when the company granted the options) and avoided any charges to book earnings in the process. And the resale restrictions created golden handcuffs without forcing executives to wait to buy their shares.

The Benefits Challenge

No startup can match the cradle-to-grave benefits offered by employers like IBM or General Motors, although young companies may have to attract executives from these giant companies. It is also true, however, that the executives most attracted to startup opportunities may be people for whom standard benefit packages are relatively unimportant. Startup companies have special opportunities for creativity and customization with employee benefits. The goal should not be to come as close to what IBM offers without going broke, but to devise low-cost, innovative programs that meet the needs of a small employee corps.

Of course, certain basic needs must be met. Group life insurance is important, although coverage levels should start small and increase as the company gets stronger. Group medical is also essential, although there are many ways to limit its cost. Setting higher-than-average deductibles lowers employer premiums (the deductibles can be adjusted downward as financial stability improves). Self-insuring smaller claims also conserves cash. One young company saved 25% on its health-insurance premiums by self-insuring the first $500 of each claim and paying a third party to administer the coverage.

The list of traditional employee benefits doesn’t have to stop here—but it probably should. Most companies should not adopt long-term disability coverage, dental plans, child-care assistance, even retirement plans, until they are well beyond the startup phase. This is a difficult reality for many founders to accept, especially those who have broken from larger companies with generous benefit programs. But any program has costs—and costs of any kind are a critical worry for a new company trying to move from the red into the black. Indeed, one startup in the business of developing and operating progressive child-care centers wisely decided to wait for greater financial stability before offering its own employees child-care benefits.

Many young companies underestimate the money and time it takes just to administer benefit programs, let alone fund them. Employee benefits do not run on automatic pilot. While the vice president of marketing watches marketing, the CFO keeps tabs on finances, and the CEO snuffs out the fires that always threaten to engulf a young company, who is left to mind the personnel store? If a substantial benefits program is in place, someone has to handle the day-to-day administrative details and update the program as the accounting and tax rules change. The best strategy is to keep benefits modest at first and make them more comprehensive as the company moves toward profitability.

Which is not to suggest that the only answer to benefits is setting strict limits. Other creative policies may not only cost less but they also may better suit the interests and needs of executive recruits. Take company-supplied lunches. One startup computer company thought it was important to create a “think-tank” atmosphere. So it set up writing boards in the cafeteria, provided all employees with daily lunches from various ethnic restaurants, and encouraged spirited noontime discussions.

Certainly, Thai food is no substitute for a generous pension. But benefits that promote a creative and energetic office environment may matter more to employees than savings plans whose impact may not be felt for decades. One startup learned this lesson after it polled its employees. It was prepared to offer an attractive—and costly—401(k) program until a survey disclosed that employees preferred a much different benefit: employer-paid membership at a local health club. The company gladly obliged.

Deciding on compensation policies for startup companies means making tough choices. There is an inevitable temptation, as a company shows its first signs of growth and financial stability, to enlarge salaries and benefits toward market levels. You should resist these temptations. As your company heads toward maturity, so can your compensation and benefits programs. But the wisest approach is to go slowly, to make enhancements incrementally, and to be aware at all times of the cash flow, taxation, and accounting implications of the choices you face.

ERM - How did WOPR decide the only winning move is not to play?

"A strange game.  The only winning move is not to play."

WOPR evolved and learned while playing against himself.  Nifty!  As WOPR drew additional power, assumedly, WOPR was able to evolve due to extrinsic / intrinsic features.  Extrinsic evolution uses software simulation of the hardware to evaluate the effectiveness of each new model. This is great where the threat may not be too specific or rather abstract. It is best to apply this to the underlying hardware due to the fact abstraction from the underlying hardware will lead to a less optimal model. Intrinsic evolution is implemented in the hardware. Each model is evaluated and implemented based upon the threat, vulnerability, and other quantitative data. This is extremely useful for deducing the risk’s properties which can not be known by traditional risk methodologies. Imagine this as if each variant in the model is downloaded to the chip as a data design configuration. Where the fitness is evaluated by applying test vectors and calculating the fitness value from its’ response.

Assuming threat characteristics, for evolvable modelling design issues, an evolutionary algorithm determines some of the structure or parameters of a reconfigurable item. This item may exist in software, although it could be a simulation of the hardware of a final implementation. The reconfigurable item might alternatively be physically changeable hardware. Typically, the item is embedded in some sort of environment, where it responds, influences, and behaves. The evolutionary model creator devises a fitness evaluation procedure that monitors and possibly manipulates the environment and items, returning objective function metrics.  An algorithm generates structural / parametric variations of the risk, by applying variation operators (mutate, cross over, etc..) to some representation of the object’s configuration. All the system gets back are the measured objective values. Another way of thinking about the evaluation / environment / object process as a black-box system.  Where WOPR played each scenario and came to the same conclusion for all "The only winning move is not to play."

Evolutionary risk modeling series

When I see organizations perform threat modeling, rarely will I see them model for threats which evolve over some period of time or react to the organization’s action / reaction. Why? I do not know. I hear it is too hard but it really isn’t. I model these evolutionary-based risks using novel evolutionary algorithms. Generally speaking, evolutionary risk modeling techniques can be split into two categories: evolutionary algorithms and evolvable hardware. At the core of the techniques is that they solve problem sets in the same manner as a human. In the public sector, evolvable hardware is extremely immature. There are many practical and cost-related challenges, which must be overcome before one may reap the benefits of large scale applications of this technology. But that doesn’t mean it isn’t being done.

Yet Another Risk Management series

In today’s rapid-paced, ever-changing economy, the topic of enterprise risk management has gained significant interest beyond the financial industry and academia. Especially with the latest buzzwords surrounding cloud security and cloud risk. Fortunately for blackhats, risk management is infantile and handled in an informal manner.

When was the last time you have attended a formal risk management meeting? Did it look like this?


 Or did it look like this?


Worse yet, there are not actuarial datasets to use. DatalossDB comes close but much works needs to be accomplished to ensure the integrity of the data is beyond reproach. Verizon’s DBIR is better than nothing, but leaves much desired to arrive at the same conclusions. To this end, I will propose a comprehensive approach to enterprise risk management based on academic and business research.

In the coming months, I look forward to constructive feedback. We shall begin exploring state-of-the-art information technology’s qualitative and quantitative risk management methodology qualities. Followed by business reasons why risk management remains in institutional neglect. Along the way, we shall have take aways from several conceptual frameworks, and explore risk management tools which have been used or could be, such as IBM OpenPages, RiskAoA, custom excel spreadsheets, and other items. Our research will draw ideals from fields not normally associated with enterprise risk management. In order to isolate important risk drivers, certain perspectives will be had, IE regulatory and political. One could say this series on risk management is to promote a greater preemptive organizational outlook. Assisting institutions to foresee and exploit a business environment’s inefficiencies and reservations. On the other hand, an evolutionary market perspective is used to articulate a novel way to uncover data in the domain of risk management. We will find there are many ways to skin a cat to produce creative solutions.

Management Wednesday: BPM Modeling - not charts anymore #bpm

After one has accomplished the scoping phase, then the team should move on to modeling. Due to the large amount of time spent scoping, many scenarios will come to light: “What if I have 50% of the resources to accomplish the same task?” “What if we were successful only because of a natural disaster which caused our competition’s supply to dwindle?”

One’s team will model how the process(es) might operate under different assumptions, and multivariate scenarios. Thanks to the birth of the transistor, it is becoming reality to be able to complete round-trip engineering and simulations. Back in the 20th century, entities utilized PERT diagrams, Gantt charts, and other interesting flow chart visual aides. A thought leader took S. William’s 1967 article about business process modeling to create UML. UML is Unified Modeling Language. UML is commonly found in the software engineering landscape. It wasn’t until the 1990s when universities started to teach UML. Personally, I use Octave in conjunction with probabilistic graph modeling (statistical analysis tool and methodology,) BlueWorks (SaaS based software,) and WebSphere (application) to get the information my team needs at their finger tips whenever they need to “play with the numbers” at any time / place.

At the most basic level, a capitalistic business process model is the base model by which a corporation defines how a company generates revenue by its’ position in the value chain. Younger organizations will not spend much time modeling because they are too busy trying to raise capital. Mature organizations will spend too much time modeling. To what degree depends on the analytical executive personas. “What if we spent X% more on lead generation?” “What if we cross sold to our partner channel while reducing sales commissions on our direct sales?”

A common business process model relies upon resource scenarios, capital scenarios, and other multivariate analysis. Which will then feedback into previous internal and industry metrics. The nifty part about modeling: as a result, there will be transparency into business processes, as well as the centralization of business process models and execution metrics. This is extremely useful during mergers and acquisitions. With this clean slate, the organization is able to fundamentally rethink how they accomplish their work to improve some metric(s.) A few metrics one can look over; operational expenditures improve customer satisfaction, remove redundant overhead, increase competitive intelligence, and more. An interesting multiplier in this clean state phase is the use of mature information services. Technology allows entities to crunch numbers and crunch them fast. No longer does one have buildings full of accountants to take over your competition with their sailboat building.  Beware though: just because your models are sound does not mean they will happen in real life.

Gribodemon on SpyEye 2.x - I expected better

Saturday, I noticed my application honeypot collected an interesting sample. The cracker took my bait and attempt to hack the planet via a SpyEye 2.x variant. Apparently, the limit of its sandbox testing was to look for known virtualized drivers, mac addresses, and other signatures typically found in / on virtualized sandboxes. Just another arrow to the quiver of changing everything default in a virtualized sandbox. Everything from PCI driver labels to ethernet mac addresses.

I am utterly amazed at the kit’s insecure coding. The small Windows executable is vulnerable to numerous buffer overflows, poor error handling, and poor cryptographic implementation. Don’t even get me started on their alleged “performance optimization.” I traced the outbound calls and dummy data exfiltration a web-based C&C system. Fortunate for me, it is a poorly coded web application. By poorly coded, there are 300+ XSS vulnerabilities, 60+ SQL injections, and numerous other poor secure coding practices. Gribo's response:  "run in a sefe place."

A typical example from the certificate handling code:

$id = $_GET['id'];

if (!$id) exit;


$dbase = db_open();

$sql = "SELECT data, bot_guid, name, date_rep FROM cert WHERE id = $id LIMIT 1";

$res = mysqli_query($dbase, $sql);

Needless to say, the C&C website was taken care of with no effort at all. While I commend Gribodemon and team offering free support, their efforts are better spent securing their kit from other crackers.

Great Git security story and suggested work arounds

People wonder why Microsoft keeps their repository secured with armed guards and what not...

"...You quickly check the history. git log --patch 3bc42b. “Added missing docblocks for X, Y and Z.” You form a puzzled expression, raising your hands from the keyboard slightly before tapping the space bar a few times with few expectations. Sure enough, in with a few minor docblock changes, there was one very inconspicuous line change that added the back door to the authentication system. The commit message is fairly clear and does not raise any red flags — why would you check it? Furthermore, the author of the commit was indeed you! Thoughts race through your mind. How could this have happened? That commit has your name, but you do not recall ever having made those changes. Furthermore, you would have never made that line change; it simply does not make sense. Did your colleague frame you by committing as you? Was your colleague’s system compromised? Was your host compromised? It couldn’t have been your local repository; that commit was clearly part of the merge and did not exist in your local repository until your pull on that morning two months ago. Regardless of what happened, one thing is horrifically clear: right now, you are the one being blamed...."


Security is hard. Security Tools are harder. Cloud Security Tools are hardest.

There are tools, security tools, and then there are cloud security tools.  Especially in the realm of security orchestration.  Many cloud snake oil tools were never designed for the cloud.  See RSA three years ago to today when a vendor slapped cloud on their marketing material for pre-existing on-premise software.  Or better yet:  They took their CFEngine and applied it to all of their customer's AWS instances.  A great example are the vulnerability managers / scanners.   Setup a DNS hostname or IP to scan.  Then the vulnerability "management" portion of the scanner will track the DNS / IP with metadata about the machine.  But what about when the IP or DNS name changes to a different IP / DNS hostname, but the machine instance stays the same? Many service-based security tools pricing structure are based upon some idea of a static concept (IP address, DNS entry, etc...)  So imagine an infrastructure where new machines are created and destroyed every few minutes.  It will get quite expensive.  Not to mention, the vulnerability / GRC management software doesn't have the concept of a machine instance jumping around the infrastructure with different IPs / DNS names but still representing the same machine scanned moments earlier.  Well, their business model understands this concept and it means more licenses and billable expenses.  This is assuming you are able to scan instances which exist for a few minutes then are terminated; you did solve that problem, right?  

Very few cloud snake oil tools have any type of API or programmatic interface by which to interact with the service or tool.  Imagine if you wanted to correlate information on everyone piggybacking into your office.  A simple correlation involves seeing who didn't swipe into the office but logged on locally to the office networked machine.  If you had to resort to scraping the building access system to get your swipes, then it doesn't have an API or programmatic interface.  One would expect to see start, stop, restart, running status, credential management, alerting, reporting, auditing, etc....  

One's mileage on the time it will take to construct / destroy the cloud security orchestration tool.  For many software-based tools, it will require a complex host or network agent.  Look at the build complexity required to run Chef: MongoDB, Solr, Rails, Ruby, etc...  Best case, the tool will require credentials or be at some trusted point in the architecture.  This is where orchestration tools will succeed.  Once you can do it for another environment, it is simple to transition the orchestration to the new environment.  Assuming one is building a mirror of their other environment.

While interoperability will always be an issue with security tools, orchestration is another beast.  Rarely, one will find one tool to natively interoperate with others.  Hence the business need for Bromium, Cloud Passage, High Cloud Security, HyTrust, and other cloud security corporations.  Ask yourself does your cloud security tool have the ability to push / pull information from your Arc Sight instance, correlate with Splunk's output, push into your GRC tool, pull the latest scan from Qualys, maintain policy compliance, and push out signatures to your Imperva instances?  How about a simpler question:  How will you pull your puppet / chef logs from Splunk or OSSEC and correlate with one's security checklist automation documentation to verify what one is seeing is a policy violation or an intrusion?  By the way, the asset which caused the violation is now destroyed by your orchestration software.  I hope your incident response team understands how to investigate cloud instances and be able to perform forensic investigations.


Airing one's dirty development laundry - You are doing it wrong

I recieved a lovely google alert this weekend.

Even with the most secret of secrets, the private key to a public / private key pair, entities manage to show their secrets to the world.  Human's err.  


Kinda reminds me of digging through development oriented copy/paste services: IE to find juicy credentials.

 You would be surprised what one would find in Web Services debugging information....


Management Wednesday: Competitor acquires one of your customers

When a competitor acquires one’s customer(s), keep an eye on their usage. Common sense would dictate the newly acquired customer would quickly transition to a new service provider. If the acquired customer does not part ways, this would allow for some interesting marketing / pr material. Better yet, when the competitor renews the contract, make sure to take note of the renewal. One could use the renewal in aggressive marketing.

A lovely case study: SAP becomes NetSuite’s latest customer.


Giving back - whitehat security training for free

When possible, I try to give back to a community which has given me much. My latest endeavor has been to assist and provide free whitehat training. For those of you who need to refresh their skillset or want to see another perspective on incident response, risk management, ethics, legal and other whitehat topics; please visit teexwmdcampus and sign up for a course or two. All of the courses are eletronic based.  You are able to proceed at your own pace.  I would love any feedback, positive or negative.

Hilarious law enforcement educational video - Who is a hacker?

These videos are why it is easier to explain "I am a rent-a-cop" than to describe information security. The scary part: This 1995 video was used to educate law enforcement.  The scarier part: the updated videos are not much better. I wonder if this fictional hacker meets his end in Untraceable.

 "Hacking is easy."

"You might as well give me the keys to your front door. I'm going to get into your system."

Management Wednesday: BPM scoping

In business process management, there is no defined starting point. The solutions are transposable, adaptive, and can be set into motion regardless of the other solution’s state. In project’s scoping minimalist form, business process management is set into motion by a timeline approach. The timeline will start with a simple set of process models and evolve into degrees of automated, real-time auditing, and dynamic execution.

• Available human capital

• Processes’ complexity

• Workflows

• Integration / disruption complexity

Many times, as with basic project management fundamentals, the inability to properly quantify resources / human capital available will lead to many BPM project failures. Yes, there will always be shortages, but do not get involved with a project which is setup for failure from the start. Beware, engineers and developers are eternal optimists.

Expect to have multiple discovery sessions with various stakeholders. Beware of going too deep. Stop discovery when you are discovering for the sake of discovering. If one has discovered the entire organization and its’ processes, then one has gone too far. Walking out of these meetings, one will have an idea on current processes’ activeness.

From the discovered processes and activity, one will be able to start modeling workflows. This is where one’s subject matter expertise will greatly speed up this phase. The more time one spends in this phase, the better. Beware of spending too many cycles in this phase. One will find 9 times out of 10, one’s specs / workflows will change after prototyping with the customer. If one decides to utilize use cases, spend less time here.  One will make up for lacking details when one begins to prototype with the customer. Attempt to be creative to enable innovative processes which align with customers’ needs to remain adaptive, agile, and competitive.

The recipe for figuring out integration / disruptive complexity: One bit of disruptive change.Two bits of human nature resistant to change. A pinch of integration / disruption complexities. Mix the ingridents together and bake in some time. Then you will end up something which doesn’t look like what you imagined. Unfortunately, time has proven no one knows the final state of the process model. The better BPM experts will get close.