Glossary of Terms

Login

Glossary

Filter:

# A B C D E F G H I J K L M N O P Q R S T U V W X Y Z All

B

B

B1

B1FF*

B2

B3

Backdoor account

Backdoor Trojan

Background checks

Background Investigations #

Background Processing

Backspace And Overstrike*

Back-To-Back Connection

Backup

Backup facility

Backup Procedures

Backup retention plan

Backward Channel

Backward Combatability*

Backward Recovery

BAD*

Band

Bandwidth Compression

Bang

Banner

Banner*

Base

Base C4 Systems Security Office

Base Computer Systems Security Officer

Basic Software (nonfunctional)

BASIC*

Basic/Generic Management Issues#

Batch Processing

Batch*

Baud

Bboard*

BBS

BCC

BCD

BCI

BCSSO

Bd

Beam*

Beep*

Behavioral scanning

Bell-La Padula Security Model

Bell-LaPadula Model

Bells And Whistles*

Benign

Benign Environment

BER

BERT

Beta*

Between-The-Lines Entry

Bible*

BiCapitalization*

Biff*

Big Red Switch*

Bignum*

Bigot*

Binary

Binary Exponential Backoff

Binary Notation

Binary Synchronous Communication

Binary-Coded Decimal

Binary-Coded Decimal Code

Binary-Coded Decimal Interchange Code

Binary-Coded Decimal Notation

Binary-Coded Decimal Representation

Binding

Binding/Handshaking#

Biometric authentication

B-ISDN

Bi-Sync

Bit

Bit Configuration

Bit Error Ratio

Bit Error Ratio Tester

Bit Stream Transmission

Bit Synchronization

Bitblt*

Bit-By-Bit Asynchronous Operation

Bit-Count Integrity

BITNET*

Bit-Paired Keyboard*

Bits Per Second

Bits*

Bit-Sequence Independence

Bit-Synchronous Operation

BIU

Bixie*

Black

BLACK Equipment Area (BEA)

Black hat hackers

Blast*

Blended threats

Blink*

Blit*

Blivet*

BLOB*

Block

Block Character

Block Check Character

Block encryption

Block Transfer Attempt

Block Transfer Computations*

Block Transfer Efficiency

Block Transfer Failure

Block Transfer Rate

Block Transfer Time

Block-Error Probability

Blocking Criterion

Blocking Factor

Blocking Formulas

Block-Loss Probability

Block-Misdelivery Probability

BLT*

Body

Border firewalls

Bourne Shell and Bourne Again Shell (BASH)

BPI

BPOC

BPS

BQS*

BR

Breach

Bridge

Broken*

Broket*

BRS*

Brute Force And Ignorance*

Brute-force guessing

BSA

BSD*

BSE

Budget

Budget And Accounting Act

Budget And Accounting Procedures Act Of 1950

Buffer

Buffer overflow

Buffer Overflow*

Bug

Bugging

Bulk Encryption

Bum*

Bump*

Burble*

Buried Treasure*

Burn-In Period*

Burst Transmission#

Bus

Bus Interface Unit

Business Aspects Of Information Security#

Business champions

Business continuity plan

Business process analysis

Buzz*

BW

BWQ*

Byte

Brute Force*

adj. Describes a primitive programming style, one in which the programmer relies on the computer's processing power instead of using his or her own intelligence to simplify the problem, often ignoring problems of scale and applying naive methods suited to small problems directly to large ones. The term can also be used in reference to programming style brute-force programs are written in a heavyhanded, tedious way, full of repetition and devoid of any elegance or useful abstraction (see also brute force and ignorance). The canonical example of a brute-force algorithm is associated with the `traveling salesman problem' (TSP), a classical NP-hard problem Suppose a person is in, say, Boston, and wishes to drive to N other cities. In what order should the cities be visited in order to minimize the distance travelled? The brute-force method is to simply generate all possible routes and compare the distances; while guaranteed to work and simple to implement, this algorithm is clearly very stupid in that it considers even obviously absurd routes (like going from Boston to Houston via San Francisco and New York, in that order). For very small N it works well, but it rapidly becomes absurdly inefficient when N increases (for N = 15, there are already 1,307,674,368,000 possible routes to consider, and for N = 1000 -- well, see bignum). Sometimes, unfortunately, there is no better general solution than brute force. See also NP-.
A more simple-minded example of brute-force programming is finding the smallest number in a large list by first using an existing program to sort the list in ascending order, and then picking the first number off the front. Whether brute-force programming should actually be considered stupid or not depends on the context; if the problem is not terribly big, the extra CPU time spent on a brute-force solution may cost less than the programmer time it would take to develop a more `intelligent' algorithm. Additionally, a more intelligent algorithm may imply more long-term complexity cost and bug-chasing than are justified by the speed improvement. Ken Thompson, co-inventor of UNIX, is reported to have uttered the epigram "When in doubt, use brute force". He probably intended this as a ha ha only serious, but the original UNIX kernel's preference for simple, robust, and portable algorithms over brittle `smart' ones does seem to have been a significant factor in the success of that OS. Like so many other tradeoffs in software design, the choice between brute force and complex, finely-tuned cleverness is often a difficult one that requires both engineering savvy and delicate esthetic judgment.