Attack path management is a cybersecurity technique that involves the continuous discovery, mapping, and risk assessment of identity-based attack paths. Attack path management is distinct from other computer security mitigation strategies in that it does not rely on finding individual attack paths through vulnerabilities, exploits, or offensive testing. Rather, attack path management techniques analyze all attack paths present in an environment based on active identity management policies, authentication configurations, and active authenticated "sessions" between objects. == Overview == Attack path management relies on concepts such as mapping and removing attack paths, identifying attack path choke points, and remediation of attack paths. Identity-based attacks are present in most publicly disclosed breaches, whether through social engineering to gain initial access to Active Directories or lateral movement for privilege escalation. Attackers require privileges to attack an environment’s most sensitive segments. Attack path management often involves removing out-of-date privileges and privilege assignments given to overly large groups. In attack path management, attack graphs are used to represent how a network of machines’ security is vulnerable to attack. The nodes in an attack graph represent principals and other objects such as machines, accounts, and security groups. The edges in an attack graph represent the links and relationships between nodes. Some nodes are easy to penetrate due to short paths from regular users to domain admins, resulting in focal points of concentrated network traffic, which are known as attack path choke points. Attack graphs are often analyzed using algorithms and visualization. Attack path management also identifies tier 0 assets, which are considered the most vulnerable because they have direct or indirect control of an Active Directory or Microsoft Entra ID environment.
Ugly duckling theorem
The ugly duckling theorem is an argument showing that classification is not really possible without some sort of bias. More particularly, it assumes finitely many properties combinable by logical connectives, and finitely many objects; it asserts that any two different objects share the same number of (extensional) properties. The theorem is named after Hans Christian Andersen's 1843 story "The Ugly Duckling", because it shows that a duckling is just as similar to a swan as two swans are to each other. It was derived by Satosi Watanabe in 1969. == Mathematical formula == Suppose there are n things in the universe, and one wants to put them into classes or categories. One has no preconceived ideas or biases about what sorts of categories are "natural" or "normal" and what are not. So one has to consider all the possible classes that could be, all the possible ways of making a set out of the n objects. There are 2 n {\displaystyle 2^{n}} such ways, the size of the power set of n objects. One can use that to measure the similarity between two objects, and one would see how many sets they have in common. However, one cannot. Any two objects have exactly the same number of classes in common if we can form any possible class, namely 2 n − 1 {\displaystyle 2^{n-1}} (half the total number of classes there are). To see this is so, one may imagine each class is represented by an n-bit string (or binary encoded integer), with a zero for each element not in the class and a one for each element in the class. As one finds, there are 2 n {\displaystyle 2^{n}} such strings. As all possible choices of zeros and ones are there, any two bit-positions will agree exactly half the time. One may pick two elements and reorder the bits so they are the first two, and imagine the numbers sorted lexicographically. The first 2 n / 2 {\displaystyle 2^{n}/2} numbers will have bit #1 set to zero, and the second 2 n / 2 {\displaystyle 2^{n}/2} will have it set to one. Within each of those blocks, the top 2 n / 4 {\displaystyle 2^{n}/4} will have bit #2 set to zero and the other 2 n / 4 {\displaystyle 2^{n}/4} will have it as one, so they agree on two blocks of 2 n / 4 {\displaystyle 2^{n}/4} or on half of all the cases, no matter which two elements one picks. So if we have no preconceived bias about which categories are better, everything is then equally similar (or equally dissimilar). The number of predicates simultaneously satisfied by two non-identical elements is constant over all such pairs. Thus, some kind of inductive bias is needed to make judgements to prefer certain categories over others. === Boolean functions === Let x 1 , x 2 , … , x n {\displaystyle x_{1},x_{2},\dots ,x_{n}} be a set of vectors of k {\displaystyle k} booleans each. The ugly duckling is the vector which is least like the others. Given the booleans, this can be computed using Hamming distance. However, the choice of boolean features to consider could have been somewhat arbitrary. Perhaps there were features derivable from the original features that were important for identifying the ugly duckling. The set of booleans in the vector can be extended with new features computed as boolean functions of the k {\displaystyle k} original features. The only canonical way to do this is to extend it with all possible Boolean functions. The resulting completed vectors have 2 k {\displaystyle 2^{k}} features. The ugly duckling theorem states that there is no ugly duckling because any two completed vectors will either be equal or differ in exactly half of the features. Proof. Let x and y be two vectors. If they are the same, then their completed vectors must also be the same because any Boolean function of x will agree with the same Boolean function of y. If x and y are different, then there exists a coordinate i {\displaystyle i} where the i {\displaystyle i} -th coordinate of x {\displaystyle x} differs from the i {\displaystyle i} -th coordinate of y {\displaystyle y} . Now the completed features contain every Boolean function on k {\displaystyle k} Boolean variables, with each one exactly once. Viewing these Boolean functions as polynomials in k {\displaystyle k} variables over GF(2), segregate the functions into pairs ( f , g ) {\displaystyle (f,g)} where f {\displaystyle f} contains the i {\displaystyle i} -th coordinate as a linear term and g {\displaystyle g} is f {\displaystyle f} without that linear term. Now, for every such pair ( f , g ) {\displaystyle (f,g)} , x {\displaystyle x} and y {\displaystyle y} will agree on exactly one of the two functions. If they agree on one, they must disagree on the other and vice versa. (This proof is believed to be due to Watanabe.) == Discussion == A possible way around the ugly duckling theorem would be to introduce a constraint on how similarity is measured by limiting the properties involved in classification, for instance, between A and B. However Medin et al. (1993) point out that this does not actually resolve the arbitrariness or bias problem since in what respects A is similar to B: "varies with the stimulus context and task, so that there is no unique answer, to the question of how similar is one object to another". For example, "a barberpole and a zebra would be more similar than a horse and a zebra if the feature striped had sufficient weight. Of course, if these feature weights were fixed, then these similarity relations would be constrained". Yet the property "striped" as a weight 'fix' or constraint is arbitrary itself, meaning: "unless one can specify such criteria, then the claim that categorization is based on attribute matching is almost entirely vacuous". Stamos (2003) remarked that some judgments of overall similarity are non-arbitrary in the sense they are useful: "Presumably, people's perceptual and conceptual processes have evolved that information that matters to human needs and goals can be roughly approximated by a similarity heuristic... If you are in the jungle and you see a tiger but you decide not to stereotype (perhaps because you believe that similarity is a false friend), then you will probably be eaten. In other words, in the biological world stereotyping based on veridical judgments of overall similarity statistically results in greater survival and reproductive success." Unless some properties are considered more salient, or 'weighted' more important than others, everything will appear equally similar, hence Watanabe (1986) wrote: "any objects, in so far as they are distinguishable, are equally similar". In a weaker setting that assumes infinitely many properties, Murphy and Medin (1985) give an example of two putative classified things, plums and lawnmowers: "Suppose that one is to list the attributes that plums and lawnmowers have in common in order to judge their similarity. It is easy to see that the list could be infinite: Both weigh less than 10,000 kg (and less than 10,001 kg), both did not exist 10,000,000 years ago (and 10,000,001 years ago), both cannot hear well, both can be dropped, both take up space, and so on. Likewise, the list of differences could be infinite… any two entities can be arbitrarily similar or dissimilar by changing the criterion of what counts as a relevant attribute." According to Woodward, the ugly duckling theorem is related to Schaffer's Conservation Law for Generalization Performance, which states that all algorithms for learning of boolean functions from input/output examples have the same overall generalization performance as random guessing. The latter result is generalized by Woodward to functions on countably infinite domains.
Evolutionary robotics
Evolutionary robotics is an embodied approach to Artificial Intelligence (AI) in which robots are automatically designed using Darwinian principles of natural selection. The design of a robot, or a subsystem of a robot such as a neural controller, is optimized against a behavioral goal (e.g. run as fast as possible). Usually, designs are evaluated in simulations as fabricating thousands or millions of designs and testing them in the real world is prohibitively expensive in terms of time, money, and safety. An evolutionary robotics experiment starts with a population of randomly generated robot designs. The worst performing designs are discarded and replaced with mutations and/or combinations of the better designs. This evolutionary algorithm continues until a prespecified amount of time elapses or some target performance metric is surpassed. Evolutionary robotics methods are particularly useful for engineering machines that must operate in environments in which humans have limited intuition (nanoscale, space, etc.). Evolved simulated robots can also be used as scientific tools to generate new hypotheses in biology and cognitive science, and to test old hypothesis that require experiments that have proven difficult or impossible to carry out in reality. == History == In the early 1990s, two separate European groups demonstrated different approaches to the evolution of robot control systems. Dario Floreano and Francesco Mondada at EPFL evolved controllers for the Khepera robot. Adrian Thompson, Nick Jakobi, Dave Cliff, Inman Harvey, and Phil Husbands evolved controllers for a Gantry robot at the University of Sussex. However the body of these robots was presupposed before evolution. The first simulations of evolved robots were reported by Karl Sims and Jeffrey Ventrella of the MIT Media Lab, also in the early 1990s. However these so-called virtual creatures never left their simulated worlds. The first evolved robots to be built in reality were 3D-printed by Hod Lipson and Jordan Pollack at Brandeis University at the turn of the 21st century.
Avid DS
Avid DS (which was called Avid DS Nitris until early 2008) is a high-end offline and finishing system comprising a non-linear editing system and visual effects software. It was developed by Softimage (this company was owned by Microsoft at the time of DS v1.0's launch before being acquired from Microsoft by Avid Technology, Inc. shortly thereafter) in Montreal. DS was discontinued on September 30, 2013 with support ending on the same date the following year. == Software == DS was called ‘Digital Studio’ in development. It was envisioned to be a complete platform for video/audio work. The first previews of the system were on the SGI platform, but this version was never released. The system was rewritten on Windows NT with different video hardware platforms (Matrox DigiSuite or Play Trinity running on a NetPower system) before the final system was released on Intergraph/StudioZ hardware in January 1998. After its acquisition by Avid, DS was always positioned as a high end video finishing tool. However, many users found it to be uniquely soup-to-nuts in its capabilities. From version 1.0 of the product, it competed with products like Autodesk Smoke, Quantel and Avid Symphony. The toolset in DS offered video timeline editing, an object-oriented vector-based paint tool, 2D layer compositing, sample based audio and starting with version 3.01 of the product, a 3D environment. Originally, a subset of the Softimage|XSI 3D software was planned to become part of the DS toolset, both were built on the same software foundation, but over time the code bases divided between the applications and the integration never happened. While the first version of the DS still lacked a few key features (no 3D, poor keying, no real-time effects), it had some significant features compared to the competing products at the time. It offered a large number of built in effects. Avid OMF import was available, positioning Softimage DS as a strong finishing tool for then typical off-line Avid systems. Lastly the integration of the toolset of Softimage DS was beyond what other product offered. A Softimage DS user could quickly go from editing, to paint, to compositing with a few mouse clicks all inside the same interface. Some of the lacking features were quickly resolved, within months of version 1.0 a new chroma keyer was released. Early versions of the software (up thru 4.0) added additional key features. Development continued with one of the first uncompressed HD editing systems (version 4.01) and an attempt to make the system more friendly to Media Composer editors in version 6. In later versions (v7.5 on beyond) DS was criticized for slow development of compositing tools, mainly lack of a new 3D environment and better tracking tools. Many DS users felt that Avid had not been giving DS the attention that it deserved. On July 7, 2013, Avid sent out an email marking the end of life of the DS product. "To Our Avid DS customers, We are writing to inform you that Avid will be realigning our business strategy to focus on a core suite of products to best leverage our developmental and creative resources. As part of this transition, we will be ceasing future development of Avid DS with a final sale date of September 30th, 2013" == Hardware == Up until version 10.5, DS was sold as a turn-key system; the software was not available without purchasing CPU, I/O and storage hardware from Avid. Beginning with 10.5, customers were able to configure their own systems using widely available components, based on recommended system requirements. In turn-key systems, there were many hardware refreshes over time. StudioZ single stream: Intergraph TDZ-425 with 30 minutes of uncompressed SCSI storage. CPUs at the time were Pentium II/300 MHz. StudioZ dual stream: Intergraph TDZ-2000 GT1 with one hour of fibre channel storage. CPUs on first systems were Pentium II/400 MHz, but last shipping systems had Pentium III/1 GHz. DS was one of the first applications to show that real-time effects could be processed with just the CPUs of the system, not requiring special video cards with real-time effect hardware. Equinox: Developed by Avid, it was one of the first uncompressed HD video cards available. Systems were available on CPUs from Pentium III/1 GHz to Pentium 4/2.8 GHz. Storage was typically SCSI, but fibre channel was also supported. Nitris DNA: Developed by Avid, the Nitris hardware was probably the largest hardware update to the system since it was released. 10-bit HD and SD support was standard. Real-time down and cross convert. This was the only hardware for DS that had on-board effect processing. This allowed a system at the time to play back dual-stream uncompressed HD effects in real-time at 16-bit precision. This was also the first hardware from Avid to support the DNxHD codec. Starting with Pentium 4, Intel Core Xeons were supported. SCSI storage was primarily used. AJA Video Systems: First available as a 4:4:4 option to be used in conjunction with Nitris hardware. Final-generation DS systems used the AJA Video Systems Kona 3 (Xena 2K) card as the only I/O for the system. The last systems shipped with two Intel Core Xeon 6-core processors. SAS is the recommended storage for these systems. == History ==
Direct voice input
Direct voice input (DVI), sometimes called voice input control (VIC), is a style of human–machine interaction "HMI" in which the user makes voice commands to issue instructions to the machine through speech recognition. In the field of military aviation, DVI has been introduced into the cockpits of several modern military aircraft, such as the Eurofighter Typhoon, the Lockheed Martin F-35 Lightning II, the Dassault Rafale, the KF-21 Boramae and the Saab JAS 39 Gripen. Such systems have also been used for various other purposes, including industry control systems and speech recognition assistance for impaired individuals. == Overview == DVI systems can be divided into two major categories of functionality: "user-dependent" or "user-independent". A user-dependent system requires that a personal voice template to be generated for a specific person; the template for this individual has to be loaded onto their assigned machine prior to use of the DVI system for it to function properly. In contrast, a user-independent system does not require any personal voice template, being intended to respond correctly to the voice of any user. They can also be categorised between "discrete recognition" and "continuous recognition". Users of a discrete recognition system must pause between each word so that the DVI system can identify the separations between each word, while a continuous speech recognition system is capable of understanding a normal rate of speech. During the mid-2000s, researchers at the National Aerospace Laboratory in the Netherlands examined the use of DVI in the "GRACE" simulator; a total of twelve pilots participated in the ensuing experiment. The tests performed reportedly revealed that, while the hardware itself functioned well, several improvements were desirable prior to real-world deployment on aircraft since DVI operations actually consumed more time in comparison to traditional existing methods. Recommendations for improvements included the adoption of simpler syntax, the achievement of a greater recognition rate, and a decrease in response times; all of the issues encountered were determined to be of a technological nature, and were deemed feasible to resolve. The researchers concluded that in cockpits, especially during emergencies where pilots have to operate entirely on their own, a DVI system could be highly relevant, but that it was not of crucial importance during most other conceivable scenarios. Around the same time, evaluations of DVI systems for civil aviation purposes were conducted within the framework of Project SafeSound, coordinated by the European Union. It involved the observation of pilot workloads in real-world cockpits and contrasting them against pilot activity in flight simulators using both conventional systems and DVI assistance. The project aimed to enhance aviation safety and to decrease the workload in both ground and flight operations via the application of enhanced audio functions. == Applications == === Aviation === Prior to its widespread deployment, a handful of conventional military aircraft were converted to trial DVI systems; examples include the Harrier AV-8B and F-16 VISTA. In another case, a General Dynamics F-16 Fighting Falcon simulator was modified with DVI for a voice control study that was undertaken by the Royal Netherlands Air Force. DVI trials have also been conducted on helicopters, including the Boeing AH-64 Apache, showing the potential to improve flight safety and mission effectiveness. Numerous modern fighter aircraft have been outfitted with DVI systems, often in combination with various other man-machine interface schemes, such as HOTAS-compliant controls and other advanced control technologies. The combination of Voice and HOTAS control schemes has sometimes been referred to as the "V-TAS" concept. A prominent fighter aircraft to be furnished with a V-TAS cockpit is the Eurofighter Typhoon. The Lockheed Martin F-35 Lightning II also features a DVI system, which was developed by Adacel. Other examples includes the Dassault Rafale and the Saab JAS 39 Gripen. Numerous aircraft have been planned to use DVI. At one stage, the United States Air Force had sought to integrate DVI upon the Lockheed Martin F-22 Raptor; however, the technology was eventually judged to pose too many technical risks at that point in time, and thus such efforts were abandoned. === Personal === By 1990, working prototypes of speech recognition systems were being demonstrated; these were being promoted for the purpose of providing an effective man-machine interface for individuals with impaired speech. Techniques employed included time-encoded digital speech and automatic token set selection. Investigations of these early DVI systems reportedly included the use of automatic diagnostic routines and limited-scale trials using volunteers. During the 2010s, various companies were offering voice recognition systems to the general public in the form of personal digital assistants. One example is the Google Voice service, which allows users to pose questions via a DVI package installed on either a personal computer, tablet, or mobile phone. Numerous digital assistants have been developed, such as Amazon Echo, Siri, and Cortana, that use DVI to interact with users. === Commercial === DVI technology has enabled automated telephone systems to be widely deployed. Many companies commonly use centralised phone systems that route callers to the correct department via such methods. Various car manufacturers have also furnished their road vehicles with DVI systems; these typically allow drivers to control infotainment systems and interact with mobile phones with more convenience than legacy methods. During the late 1980s, investigations into the use of DVI systems for controlling CNC machines and other manufacturing apparatus were underway. During the 2010s, such systems were being used for logistics and warehouse management purposes.
Software bot
A software bot is a type of software agent in the service of software project management and software engineering. A software bot has an identity and potentially personified aspects in order to serve their stakeholders. Software bots often compose software services and provide an alternative user interface, which is sometimes, but not necessarily conversational. Software bots are typically used to execute tasks, suggest actions, engage in dialogue, and promote social and cultural aspects of a software project. The term bot is derived from robot. However, robots act in the physical world and software bots act only in digital spaces. Some software bots are designed and behave as chatbots, but not all chatbots are software bots. Discussions about the past and future of software bots show that software bots have been adopted for many years. == Usage == Software bots are used to support development activities, such as communication among software developers and automation of repetitive tasks. Software bots have been adopted by several communities related to software development, such as open-source communities on GitHub and Stack Overflow. GitHub bots have user accounts and can open, close, or comment on pull requests and issues. GitHub bots have been used to assign reviewers, ask contributors to sign the Contributor License Agreement, report continuous integration failures, review code and pull requests, welcome newcomers, run automated tests, merge pull requests, fix bugs and vulnerabilities, etc. The Slack tool includes an API for developing software bots. There are slack bots for keeping track of todo lists, coordinating standup meetings, and managing support tickets. The ChatBot company products further simplify the process of creating a custom Slack bot. On Wikipedia, Wikipedia bots automate a variety of tasks, such as creating stub articles, consistently updating the format of multiple articles, and so on. Bots like ClueBot NG are capable of recognizing vandalism and automatically remove disruptive content. == Taxonomies and Classification Frameworks == Lebeuf et al. provide a faceted taxonomy to characterize bots based on a literature review. It is composed of 3 main facets: (i) properties of the environment that the bot was created in; (ii) intrinsic properties of the bot itself; and (iii) the bot's interactions within its environment. They further detail the facets into sets of sub-facets under each of the main facets. Paikari and van der Hoek defined a set of dimensions to enable comparison of software bots, applied specifically to chatbots. It resulted in six dimensions: Type: the main purpose of the bot (information, collaboration, or automation) Direction of the "conversation" (input, output, or bi-directional) Guidance (human-mediated, or autonomous) Predictability (deterministic, or evolving) Interaction style (dull, alternate vocabulary, relationship-builder, human-like) Communication channel (text, voice, or both) Erlenhov et al. raised the question of the difference between a bot and simple automation, since much research done in the name of software bots uses the term bot to describe various different tools and sometimes things are "just" plain old development tools. After interviewing and surveying over 100 developers the authors found that not one, but three definitions dominated the community. They created three personas based on these definitions and the difference between what the three personas see as being a bot is mainly the association with a different set of human-like traits. The chat bot persona (Charlie) primarily thinks of bots as tools that communicates with the developer through a natural language interface (typically voice or chat), and caring little about what tasks the bot is used for or how it actually implements these tasks. The autonomous bot persona (Alex) thinks of bots as tools that work on their own (without requiring much input from a developer) on a task that would normally be done by a human. The smart bot persona (Sam) separates bots and plain old development tools through how smart (technically sophisticated) a tool is. Sam cares less about how the tool communicates, but more about if it is unusually good or adaptive at executing a task. The authors recommends that people doing research or writing about bots try to put their work in the context of one of the personas since the personas have different expectations and problems with the tools. == Example of notable bots == Dependabot and Renovatebot update software dependencies and detect vulnerabilities. (https://dependabot.com/) Probot is an organization that create and maintain bots for GitHub. The example bots using Probot are the following. Auto Assign (https://probot.github.io/apps/auto-assign/) license bot (https://probot.github.io/) Sentiment bot (https://probot.github.io/apps/sentiment-bot/) Untrivializer bot (https://probot.github.io/apps/untrivializer/) Refactoring-Bot (Refactoring-Bot): provides refactoring based on static code analysis Looks good to me bot (LGTM) is a Semmle product that inspects pull requests on GitHub for code style and unsafe code practices. == Issues and threats == Software bots may not be well accepted by humans. A study from the University of Antwerp has compared how developers active on Stack Overflow perceive answers generated by software bots. They find that developers perceive the quality of software bot-generated answers to be significantly worse if the identity of the software bot is made apparent. By contrast, answers from software bots with human-like identity were better received. In practice, when software bots are used on platforms like GitHub or Wikipedia, their username makes it clear that they are bots, e.g., DependaBot, RenovateBot, DatBot, SineBot. Bots may be subject to special rules. For instance, the GitHub terms of service does not allow 'bots' but accepts 'machine account', where a 'machine account' has two properties: 1) a human takes full responsibility of the bot's actions 2) it cannot create other accounts.
AppyStore
AppyStore is a comprehensive learning videos and games app for kids up to the age of 8 years. The platform developed by Mauj Mobile, a mobile value-added services (VAS) provider curates content to help in child development by leveraging technology. Mauj is funded by Sequoia Capital, Westbridge Capital and Intel Capital. == Background == AppyStore was launched in 2014 as a platform providing content for kids between the ages of 1.5 and 6 years. AppyStore subsequently extended its services for kids up to 8 years of age. The company operates on a subscription-based model and claims to have 5,000 learning games and videos segregated in 18 learning areas developed to help children gain optimal skills and qualities. According to an article published in Business Standard, the application is claimed to be one of the top 5 apps that help to enhance the logical and imaginative capabilities of children. AppyStore was awarded the Best app for kids by Google Play in December 2017. == Service == The company provides content via a website and an Android app. The website and android app provide learning games, rhymes, phonics, reading, stories, science, numbers, maths, logic videos comprising puzzles, worksheets, videos and fun activities and the premium subscription also includes physical worksheets which are home delivered. This content is educational and has been handpicked by teachers and experts with an understanding of the major areas of child development milestones for children up to 8 years of age. The mobile application also allows parents to track the progress of their child on the basis of the number of videos viewed.